Mon 08 Mar 2010 07:33:57 PM UTC, comment #13:
A better fix applied in 25ff9f7.
|
Fri 08 Aug 2008 07:54:07 AM UTC, comment #12:
Screen now sends the otherwise unnecessary line-erase sequence again, so as to avoid this bug.
Addressed for 4.1.0 in c64cccb.
|
Fri 08 Aug 2008 07:49:16 AM UTC, comment #11:
VTE glitch tracked at http://bugzilla.gnome.org/show_bug.cgi?id=542087
|
Sun 13 Jul 2008 08:19:51 PM UTC, comment #10:
Er, ignore the bash bit: that would be for a completely different issue than this one.
|
Sat 12 Jul 2008 08:50:35 PM UTC, comment #9:
Chet Ramey has informed me that bash-4.0 will be better behaved, probably checking for TERM being "eterm*" as well as ETERM having "term".
Should probably still avoid the behavior on older bashes, though.
|
Tue 08 Jul 2008 08:55:28 AM UTC, comment #8:
Attaching relatively minimal shell script that demonstrates the gnome-terminal problem using direct escape sequences (without screen): scr-fix-min.
Run like:
$ export COLUMNS LINES # Important!
$ ./scr-fix-min
This is clearly a gnome-terminal bug, and not screen's; however, if we can work around it relatively easy, it may be worth doing.
The chief difference in behavior in the current screen sources as opposed to screen 4.0.3, is that the release version would issue an "erase line" sequence before writing the hardstatus line, whereas the current sources don't do that. Add a "-e" option to ./scr-fix-min to add that erase-line behavior, and watch the line update properly with that addition.
Aside from adding the "erase line" sequence back into the hardstatus routines, you can also avoid the trouble by telling screen not to use the "change scroll region" sequence from xterm in your .screenrc:
terminfo xterm* cs@
(file #16029)
|
Tue 08 Jul 2008 01:54:24 AM UTC, comment #7:
Some versions of gnome-terminal don't start having problems until a second "prompt" is at bottom of screen. If "bar" is showing up, try the new gtupdate.sh script and check if "baz" is also showing up in the hardstatus.
|
Tue 08 Jul 2008 12:44:00 AM UTC, comment #6:
Interestingly, it still has the same issue when being run nested inside a screen session, so it's not just a "last line" glitch.
|
Tue 08 Jul 2008 12:36:47 AM UTC, comment #5:
Attaching:
gtupdate.sh - a shell script that reproduces the problem. Setting the SCREEN env var will change what path gtupdate.sh uses to invoke screen.
The script will emulate a screen session in which the shelltitle has been set to change based on the currently-running command, with a hardstatus at the bottom of the screen. It then issues text that screen will perceive as a title-changing "prompt", followed by the "command" foo, and an empty prompt-line. A 1-second wait occurs after each "prompt" issue.
The script then moves the cursor to the bottom of the window, and issues a "prompt" with the command bar. You'll see that the hardstatus does not appear to update when using the current development sources under gnome-terminal, and does for all other circumstances (other terminals (at least xterm), and previously released versions of screen)
scr-rel: the output of this program running the 4.0.3 release of screen within gnome-terminal under the "script" command.
scr-dev: the output of this program running the current dev sources of screen within gnume-terminal under the "script" command.
scr-diff: A universal diff between escape-sequence analysis of scr-rel and scr-dev (generated by a WIP program of mine).
(file #16020, file #16021, file #16022, file #16023)
|
Wed 25 Jun 2008 06:57:03 AM UTC, comment #4:
Okay, now we're getting somewhere: it has nothing to do with escape sequences sent by vim, it has everything to do with the fact that, when altscreen is disabled, running vim will place the cursor at the bottom of the screen. The glitch may be reliably reproduced by simply moving to the last available line. After pressing the newline that triggers the upwards-scroll of the terminal space, the hardstatus line will only update once; then the next time it will not.
I'm starting to suspect the bug is in gnome-terminal (particularly since xterm, which uses the same terminfo description, does not exhibit the problem); but the fact remains that screen 4.0.3 didn't trigger the behavior, while current sources do. It'd be useful to find the trigger, and avoid it if possible (while notifying the gnome folks of the problem).
|
Wed 25 Jun 2008 03:40:42 AM UTC, comment #3:
Can't reproduce in xterm.
|
Wed 25 Jun 2008 03:24:46 AM UTC, comment #2:
Trying to reproduce this bug at home, I'm finding that it's not quite accurate. The window title is actually changing; it's the hardstatus line that isn't.
hardstatus alwayslastline '%t'
will change with the title; but once a heavy-duty terminal app such as vim is started and stopped a couple times, the hardstatus doesn't change thereafter.
At home, I can see that it actually is changing, but appears to be "masked out". That is, I can actually watch the top couple of pixel-rows change correctly, while the rest stay the same. On my work machine, the whole row appears to remain unchanged. Watching the window list via C-a " from another terminal, I see that the title actually does change.
If I change to a different window and then change it back, I'll be able to watch the hardstatus line change for "sleep 1" and back; thereafter it continues under the former problem.
A terminal that never runs other than simple apps, such as "sleep 1", does not appear to exhibit the problem. screen 4.0.3 also does not exhibit this problem.
Testing so far has been done under gnome-terminal.
|
Wed 25 Jun 2008 12:31:27 AM UTC, comment #1:
(I meant to say how)
After running vim or emacs -nw a couple of times, the window title is no longer updated with the currently-running command. It's probably some special escape sequence interfering.
|
Wed 25 Jun 2008 12:22:57 AM UTC, original submission:
Using the special SEARCH|NAME syntax, apparently window titles can lose their "specialness", and stop being updated by the prompt, when set up with the \Ek\E\\ sequence.
This appears to be a regression over 4.0.3.
|