Created attachment 225286 [details]
This is the example of 0.34.0 (not working)

As you can see in the second attachment, the last few underscores are missing.

My bash prompt (256-color):

PS1=$'\\[\\033[4m\\]\\[\\033[38;5;118m\\]                                                                                     \r                                          \r\\[\\033[0m\\]\\n\\[\\033[38;5;118m\\]\\[\\033[48;5;233m\\]                                                            Load: \\[\E[38;5;45m\\]0.01\\[\E[38;5;118m\\] \\[\E[38;5;43m\\]0.08\\[\E[38;5;118m\\] \\[\E[38;5;41m\\]0.15\\[\E[38;5;118m\\] \342\225\255\342\224\200\342\225\256 \r                                   --\342\235\250 \\[\E[38;5;41m\\]5 users\\[\E[38;5;118m\\] \342\235\251--\r \342\225\255\342\224\200\342\225\256 \\[\E[38;5;45m\\]Linux\\[\E[38;5;118m\\] \\[\E[38;5;43m\\]3.6.0\\[\E[38;5;118m\\] \\[\E[38;5;41m\\]rc7\\[\E[38;5;118m\\]\\[\\033[0m\\]\\n\\[\\033[4m\\]\\[\\033[38;5;118m\\]\\[\\033[48;5;233m\\]                                                                           pts/3 \342\225\260\342\224\200\342\225\257 \r                                  <marduk@flagship>\r \342\225\260\342\224\200\342\225\257 Thu Sep 27\\[\\033[0m\\]\\n\\[\\033[38;5;230m\\][\\[\\033[38;5;118m\\]\\[\\033[38;5;2m\\]\\[\\033[1m\\]\342\230\221 \\[\\033[0m\\]\\[\\033[38;5;118m\\]\\[\\033[38;5;123m\\]\342\210\277\342\210\277\\[\\033[0m\\] \\[\\033[1m\\]MetaLexile\\[\\033[0m\\]\\[\\033[38;5;123m\\]\342\201\267\342\201\270\\[\\033[0m\\] \\w\\[\\033[38;5;230m\\]]\\[\\033[38;5;118m\\]\\[\\033[0m\\]\\[\\033[38;5;220m\\]\342\214\230 \\[\\033[0m\\] '

Please attach a script(1) log of that 'prompt', and use git bisect to find the problematic commit.

(In reply to comment #3)
> Please attach a script(1) log of that 'prompt', and use git bisect to find the
> problematic commit.

You're kidding me, right?  If I had the time and skills to do all that I wouldn't waste me time here and just fix the bug myself.  Is this self-serve bug fixing?  Would you like a patch with that, too?

A patch is appreciated in fact, yes.

(In reply to comment #2)
That prompts string got mangled by bugzilla's fixed column width. Can you please attach the prompt as a text file - or better yet, attach the script you are using to generate it?

(In reply to comment #5)
> A patch is appreciated in fact, yes.

As much as I'd like to say otherwise, I possess neither the knowledge to write scripts to find where the problem resides, nor would I be able to provide a patch to fix said problem.  There also appears to be a lack of interest on the part of the product maintainers.  As as a result I am closing out this report.  A sufficient work around would be to use an earlier version of the product that doesn't have the bug - or better yet, use instead any of the other better alternatives to this product.

(In reply to comment #7)
> As much as I'd like to say otherwise, I possess neither the knowledge to write
> scripts to find where the problem resides, nor would I be able to provide a
> patch to fix said problem.  There also appears to be a lack of interest on the
> part of the product maintainers.  As as a result I am closing out this report. 
> A sufficient work around would be to use an earlier version of the product that
> doesn't have the bug - or better yet, use instead any of the other better
> alternatives to this product.

Comments like this are an *excellent* way to make sure that developers will have no motivation to look at bug reports :/

As I said in comment #6, you didn't provide sufficient information for others to reproduce the bug. Asking you to run "git bisect" was therefore a perfectly reasonable request on the part of vte maintainers trying to pinpoint exactly where the problem might be. Of course many bug reporters do not know what bisect means or how to do it (in which case, they should ask!). But you listed git as one of your highlighted areas of expertise on your googleable resume - which means you do know how to do it, and therefore I am quite baffled by your reaction.

Please don't change bug status.  That's for developers to decide.

In a more serious note: don't know what's about vte that attracts people with highest self-granted sense of entitlement to upstream developer time and attention.  I have maintained many many modules.  In all other modules, bug reporters are appreciative if I just reply to their report.  In vte,/ gnome-terminal, alas, things like this report are more norm than the exception.  What truly amazes me is that their sense of entitlement persists even in the face of detailed explanation that my time is not theirs and they should earn it.

I think I know why vte draws this otherwise outlier kinds of reports: Most of the times, the person in question fits this profile: they are in love of their command line, they like to configure their Linux in a 1000 nonstandard ways.  They are so proud of their awesome cmdline skills.  They think GUIs are for n00bs.  Yet they are not hardcore programmers.  They are either pseudo-programmers, or programmer-wannabes.  Many of them call themselves sysadmins.

In the case of this report, I don't want to get personal, but since it was already mentioned, I checked out the resume of the reporter as well.  For someone who opens his resume with these "areas of expertise": "Bourne Shell, JavaScript/JQuery, Python, Povray, Ruby, SQL, VBScript, Django, subversion, git, mercurial", it's surprisingly against their exhibited profile to:

1) not know what a "script(1) log" is [1],
2) not know that "script(1)" refers to a man-page and hence to learn what it is,
3) not know how to git bisect,
4) not know that finding the commit that introduced the bug is not fixing the bug [2],
5) not know how Free Software works,

Anyway, sorry if this ended up erading like a rant.  It's something I would have wanted to say for years.  Perhaps I should have posted it in my blog, but I really tried to stay within the code of conduct.

behdad

[1] "I possess neither the knowledge to write scripts to find where the problem resides,"
[2] "nor would I be able to provide a patch to fix said problem."

(In reply to comment #8)
> As I said in comment #6, you didn't provide sufficient information for others
> to reproduce the bug. Asking you to run "git bisect" was therefore a perfectly
> reasonable request on the part of vte maintainers trying to pinpoint exactly
> where the problem might be. Of course many bug reporters do not know what
> bisect means or how to do it (in which case, they should ask!). But you listed
> git as one of your highlighted areas of expertise on your googleable resume -
> which means you do know how to do it, and therefore I am quite baffled by your
> reaction.

My apologies if enough information was not provided.  What I sought to do was provide the latest known release of where the regression did not exist, the earliest known revision of where the regression occurs, and the simplest known way to reproduce the regression.  This is what I know how to do and have done many times in the past (both as a user and a maintainer) and usually there is not a problem with that.  I have created or contributed to a few GNOME modules over the years and this is the first time I have been asked such a thing. However, I have no intimate knowledge of vte and don't neither care  to nor have the time to care to possess intimate knowledge of every individual peice of software I use (open source or not).   In my many years using and being involved with OSS, this is the first time I've heard of or been asked to, as a *user* "git bisect" to find the exact place where the error occurred.  Yes I know how to type "git bisect", but know, I don't know how to reproduce the error based on a checked out revision of the source nor should I, as a *user* be expected to.  Even when I've submitted bugs to the Linux kernel I've never been asked that.  I've been asked on some projects to "try this patch" a few times (and sometimes I can and sometimes I can't). but that's it.

Anyway I'm sorry for closing the bug.  I didn't know it was against the rules, but as I didn't have the skills/time to provide any of the information that was required to proceed, it felt like the most reasonable way to proceed.

I had no intent to come off as a know-it-all.  In fact, just the contrary.  One who does not know it all (and doesn't care to).  If I know something, I say so.  If I don't, I say so. However is possible that I don't know how Free Software works.  This has truly been an enlightening experience for me.

I in no way wish to have Gentoo developers shown in bad light.  I think they are some of the best examples of contributers of Free Software and are a shining example to all.  It is for that reason that if he says I need to apologize I do so.   So as my "final word" if you will, I would like to say I apologize if you thought my words rude or my actions (or lack thereof) unreasonable.

Thank you for your attention and contribution.

Why don't check with intermediate 0.33.x versions? It should be easy to do playing a bit locally with Gentoo ebuilds...