Bugzilla Bug 91055

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 an attachment (id=57986) [edit]
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 an attachment (id=58076) [edit]
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...