GNOME Bugzilla – Bug 127979
terminal emulation problems when using (screen) irssi
Last modified: 2006-03-12 16:42:03 UTC
In gnome-terminal-2.4.2-1 as packaged in Sid, the terminal emulation sometimes gets screwed up when switching between tabs. The behaviour is predictable and reproducible, like so: 1) Start up screen (sid's, 4.0.1-3). (Not sure if this step is necessary.) 2) Start up irssi (from sid's irssi-snapshot-0.8.6+cvs.20031114-1, though I recall other, also stable, versions of irssi bringing this problem about). 3) Create another tab. 4) Switch between the tabs a bit, returning to the irssi tab. 5) Soon, probably when irssi updates its status bar, the irssi display goes all screwy. Ctrl-L-induced redraw _temporarily_ helps, but it's screwed up again soon, probably at the next status bar update. Resizing the window (eg. maximising and unmaximising) helps, but the problem reappears when tabs are again switched back and forth. The problem is persistent and rather uncomfortable. Oh, I use an UTF-8 locale and charset in irssi as well as in screen, in case that affects this.
*** Bug 117566 has been marked as a duplicate of this bug. ***
*** Bug 126358 has been marked as a duplicate of this bug. ***
I think this is vte --> vte Reporter from bug 126358 mentions that he uses "Screen version 3.09.15 (FAU) 13-Mar-03" and it only occurs on his pc (not when ssh-ing to another pc).
*** Bug 130037 has been marked as a duplicate of this bug. ***
*** Bug 134949 has been marked as a duplicate of this bug. ***
As mentioned in the bug 13949 duplicate, this also occurs on Fedora Core 1. It also occurs with ssh sessions from Fedora Core 1 to a Debian sid box. The versions of screen and irssi affected are 4.00.02 and 0.8.6 on sid machine, and 3.09.15 and 0.8.8 on FC1, respectively. FC1's gnome-terminal is version 2.4.0.1. I haven't tested this with other versions of screen and irssi, and haven't been able to reproduce it on other apps. Also, see that duplicate for a slightly more detailed/deterministic method of producing the problem.
*** Bug 136800 has been marked as a duplicate of this bug. ***
Bug 136800 adds that this also occurs without tabs, when using a semi-transparent background.
I can reproduce the corruption with no tabs and a transparent background, with no tabs and an image as a background, or when more than one tab open. When not using any background or tabs screen + irssi + gnome-terminal works fine. Another thing to note is that irssi works fine in gnome-terminal outside of screen with tabs and transparent/image backgrounds. Fedora-devel screen-4.0.1-4 irssi-0.8.9-0.fdr.3.1.90 gnome-terminal-2.5.90-1.1 vte-0.11.10-5.1
Apparently attaching to the screen while having TERM=vt102 works as a workaround for this problem (the usual terminal type being "xterm"). Spesifically, when I attach to my irssi screen like so: TERM=vt102 screen -dr ...and switch tabs like crazy, magically nothing gets screwed up. Hope this helps in diagnosis of the problem.
Found another program that triggers this bug: btlaunchmanycurses, at least when there are enough torrent files so that it has to scroll them, showing each in turn for a while. This too requires screen to be in the middle of the terminal and the application. The TERM=vt102 workaround does not seem to work in this case, so the trigger must be a tad different.
*** Bug 142948 has been marked as a duplicate of this bug. ***
Created attachment 29544 [details] 'script' output that causes the problem This output from 'script' is pretty huge. If anybody can repeat this bug via script sooner, I'm sure that it would make the bug easier to find.
Created attachment 29569 [details] A typescript file demonstrating the problem Here's a typescript file from attaching an irssi screen. The sequence: 1) I reattach (don't be confused by the "testing 123 456" that's already on screen, it took a couple of tries before getting results right away). 2) I type "joo, bugaa", and the result is given back to me in the irssi window as is shown in the log. All is fine. 3) I switch tabs back and forth. 4) I type "koitetaanpa", and right when I press enter, the display goes all screwy, so it's most likely some of the control stuff that's on the same line that shows the same text reflected back at me (as "< mjr> koitetaanpa") or right after that. 5) I detach the screen and quit script. Hope this helps.
"me too" and this (recently) has started happening randomly even when not using tabs. (before it would happen only when using tabs or when changing the system theme or font or some other setting like that).
Then maybe it has something to do with the matcher code since that was previously per tab and is now one shared thing across all tabs? This was done to reduce memory consumption during the last cycle IIRC.
*** Bug 319346 has been marked as a duplicate of this bug. ***
I'm not sure this has anything to do with UTF-8. I still get this problem occassionally, though I cannot reproduce it at whim any longer. The machine running gnome-terminal does have UTF-8 installed, but the remote machine has no idea what to do with utf-8.
removing utf-8 again (the one time I tested it I could only reproduce under utf-8, but that was a long time ago.. perhaps changed)
*** Bug 322873 has been marked as a duplicate of this bug. ***
Confirming this on Ubuntu Dapper, updated 23.2.2006. Gnome-terminal version is 2.13.91. Screen version 4.00.02 (FAU) 5-Dec-03. I wonder if the irssi theme in question affects this bug, I'm using the "laaama-2" theme (from http://irssi.org), which doesn't have the blue bar, for an example. My locale is fi_FI.utf8 and everything is in utf8 mode, except for some channels in irssi that are set /recode iso88591. I've seen this bug ever since I've used gnome-terminal - that was back in Gnome 2.6, I think. I didn't use an utf8 locale back then.
This bug has been annoying me for ages. Just to make things interesting (mini-bounty). If anyone fixes this in time for the fix to be included in Dapper then I will buy them a music CD of their choosing (within reason). The fix must be included in the release CD image of Dapper to qualify.
I have a feeling that this is a dup of bug 104841 that I recently submitted a patch for. Ryan, can you test?
Step 2: Get the fix into Dapper (should not be difficult). Step 3: Profit! *** This bug has been marked as a duplicate of 104841 ***