Since updating to the new ncurses-5.4.20050319, irssi doesn't scroll it's output. When the screen fills with text, instead of scrolling, it just replaces the last line with the most recent line, and leaves all the rest alone. I have tried both re-emerging irssi and ncurses. This occurs with irssi0.8.10_rc5-r1. The problem does not occur if I downgrade to ncurses-5.4. I didn't notice any problems in any other programs. Reproducible: Always Steps to Reproduce: 1. Start irssi 2. Cause the screen to fill up with text, e.g. by connecting to a server Actual Results: Every time a new line was added, the others should have been moved up one. a a b b c -> c d d e f Expected Results: The others remained in their places, and the last line was replaced by the new line. a b b c c -> d d e e f Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.6.11 ccache version 2.4 [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.3 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo http://www.gigaload.org/gentoo.org/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac aalib acl alsa apache2 apm avi berkdb bitmap-fonts cdparanoia crypt cups curl dvd emboss encode fam flac foomaticdb fortran gd gdbm gif gpm gstreamer gtk gtk2 guile imagemagick imlib java jpeg libg++ libwww mad mikmod mmx mmx2 motif mozilla mp3 mpeg mysql ncurses network nls nptl nvidia offensive ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline real samba sdl session sockets spell sse sse2 ssl svg svga tcltk tcpd theora tiff truetype truetype-fonts type1-fonts unicode vorbis win32codecs xinerama xml xml2 xmms xv xvid zlib" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
This isn't an irssi specific issue, same thing happens with mutt. Mike, any idea?
this has come up before, see Bug 43432 and its dupes/dependent bugs anyone care to track down the terminal info on this one ? :P eterm / nano works fine for me
Am using eterm and mutt, and have the problem.
*** Bug 91300 has been marked as a duplicate of this bug. ***
I get it with Terminal (the XFCE one) and irssi.
I reported bug #91300 against mutt; it was marked as a duplicate of this bug. Looking over the comments here, I masked sys-libs/ncurses-5.4.20050319 and emerged back down to ncurses-5.4-r6, and mutt's normal behavior has resumed. (I use mutt within Eterm, but I just noticed that, although most of my term-related envars say Eterm, I have TERM=xterm, and xterm was one of the terminfo files that changed between the two ncurses versions.) Perhaps the owner can change the bug title to reflect the ncurses focus?
Created attachment 57986 [details, diff] ncurses-5.4.20050319-xterm.patch this is a forward port of the patch we applied to ncurses-5.4 when we had the same problem ... can people try it out ?
Thomas: could you take a look at this please ? it seems that with ncurses-5.4, if we dont set the ncurses/xterm terminfo to use xterm-xf86-v43, scrolling in apps like irssi/mutt/nano get all screwy ... it also works if i build with the configure option --without-xterm-new, but that's no fun :) simple way i found to reproduce it was to launch an Eterm, export TERM to xterm, and then edit a file with nano and page up / page down in it ... sometimes lines wouldnt be redrawn correctly or launch irssi, connect to a server, and watch the motd not scroll properly ...
Judging from the differences, it almost looks like something to do with: parm_index indn SF Scrolls forward #1 lines. (G) from diff-ing the infocmp information. I'm still trying to work it out and I ended up getting somewhere with it.. just wasn't able to securely guarantee what I did was the fix.
yes - I pointed this out before (emulators that identify as "xterm" are subject to this problem). Eterm is a bad example since its developer does try to make a workable termcap for it. gnome-terminal is the usual (inverted) "good" example since it doesn't implement the parm_indx and doesn't document anything. The feature in question is something that xterm's implemented for quite a while, but is not a vt220 escape sequence. It's one of the ISO-6429 sequences (that I've had a test-screen in vttest for - I forget - since 1999 or before)
so would you suggest we fix gnome-terminal or work around the issue by using the posted patch here ? i'm not much of a term expert ;)
I'd rather fix gnome-terminal. The simple fix for it is to simply make it set TERM to "gnome".
sounds good to me too :) everyone who has this bug, what terminal are you experiencing it in and what do you have $TERM set to when you hit it ? (run `echo $TERM` to find out) if you're using gnome-terminal, does exporting 'TERM' to 'gnome' resolve this issue for you ? when i use eterm with TERM set to 'Eterm', everything works fine
TERM is set to xterm setting it to gnome in gnome-terminal fixes this.
thanks thomas, i'll attach a patch to fix gnome-terminal :)
Created attachment 58076 [details, diff] gnome-terminal-2-gnome-TERM.patch GNOME team, please add this patch to gnome-terminal so it will export the correct TERM setting
It's not just GNOME terminal - it also occurs in xfce-extra/terminal for me (known as Terminal).
Terminal is working on my machine :/ i tried with both irssi connecting to irc.freenode.net and watching the motd scroll properly, and then launching nano on a big file and no lines were redrawn incorrectly
*** Bug 91633 has been marked as a duplicate of this bug. ***
>everyone who has this bug, what terminal are you experiencing it in and what do >you have $TERM set to when you hit it ? (run `echo $TERM` to find out) xterm >if you're using gnome-terminal, does exporting 'TERM' to 'gnome' resolve this >issue for you ? yes. There are also I believe some other outstanding gnome-terminal/irssi (possibly ncurses in general) weirdnesses. When running irssi within screen, changing GTK themes causes ncurses rendering issues. These issues are persistent within that `screen irssi` session. I can reproduce them and give more info if it's useful =)
Just wanted to add that this also happens with aterm when TERM is set to 'xterm'. Setting it to 'gnome' helps, but I do not know if this is the right thing to do.
iirc, "aterm" is identical to rxvt in this area. There's an "rxvt" terminfo entry which is suitable.
I think the connection is the 'xterm' terminfo file. 1) It was one of the changed files in the new ncurses package. 2) Multiple terminal programs (Eterm, aterm, gnome-terminal) have problems with TERM=xterm that go away when TERM is set to some other value.
true - the point is that each of these (including xterm) is a program which differs from the others - and none of them match xterm exactly. That's why there are separate terminfo entries for each.
setting eterm to use TERM=xterm is wrong, use TERM=Eterm
Anyone else tried gnome-terminal 2.10.0? It seems to (!) work properly with the 'xterm' terminfo file, not that it really SHOULD be claiming to be xterm, but at least it seems to work now.
(In reply to comment #26) > Anyone else tried gnome-terminal 2.10.0? It seems to (!) work properly with the > 'xterm' terminfo file, not that it really SHOULD be claiming to be xterm, but at > least it seems to work now. I just read ciaranm's thread on the mailing list. FWIW, I run x86 stable and have been using gnome-terminal 2.10.0 for however long now, and until I saw that thread, I didn't know that there was anything wrong. So it WorksForMe(TM).
the issue is now back, although the results look a bit different. can we just ignore the fact that the Gnome people are stubborn and patch this locally? :)
if by 'patch this locally' you mean gnome-terminal, then yes if you mean ncurses, then no
oh, also, gnome-terminal 2.12* fixes this, but TERM is of course still set wrong, so... it'll probably happen again. and yes I do mean patch gnome-terminal. ncurses reflects exactly what it should. ...although I do somewhat take issue with the fact that ncurses, as such a ubiquitous piece of software, is still stuck providing its own terminfo files. one would think that by now, terminal emulators would be providing their own terminfo files so that they actually reflected the _installed_ version of that terminal emulator, but alas... (and of course this part isn't something Gentoo can do anything about)
well, keeping a huge database in ncurses itself is a huge benefit ... consider the remote machine where no X is installed thus no gnome-terminal/eterm/etc... where would the terminfo files for these terms come from if not ncurses ? otherwise, you'd get the nasty 'unknown terminal' error message when you ssh-ed into said remote box from a gnome-terminal/eterm/etc...
mmm, point taken. I guess it might make sense to have versioned ones -- e.g. gnome-terminal says it's the same as xterm-x.y.z and ncurses has a terminfo file for a range that contains that version...
(In reply to comment #31) > where would the terminfo files for these terms come from if not ncurses ? > otherwise, you'd get the nasty 'unknown terminal' error message when you ssh-ed > into said remote box from a gnome-terminal/eterm/etc... As you currently do with rxvt-unicode?
we will apply and test this patch when the first 2.13 beta/rc hits portage. ( target the 2.14 release ) This should happen within the next month or so. Thanks
(In reply to comment #34) > This should happen within the next month or so. and 4 months later... nothing happened ;)
no, things did happen. we have the patch ready to go, but are waiting on: bug #122566 also see bug #122562, bug #122494, others we had to get fixed before applying in tree. Also, if you look in 2.14 gnome-terminal you will see a line: # patch gnome terminal to report as GNOME rather than xterm with the patch commented out, just awaitng 122566 to be resolved.
+ re-enable patch to report as "gnome" and not "xterm". see #91055 and + #122566. archs, this revision is not to be stabled with 2.14.2. ncurses dep was added to ensure people have the revision with the correct patches. We'll see what happens with unstable users to see if there are any reported bugs due to this switch. marking as fixed now.
I don't feel like rooting around to reproduce all of this right now, but I'll mention that even with TERM=gnome I was having issues a few months ago, and finally got fed up and ditched anything VTE-related (xfce-extra/Terminal is b0rked, too, pretty much identically). Not reopening, as I'm not going to pursue reproducing it, but I'd guess it still happens, so if anyone stumbles on this bug...
