I contacted the maintainer to find out whether this is really a bug, and the answer is... maybe.
From tom@invisible-island.net Sat Sep 15 12:29:37 2001 Return-path: <tom@invisible-island.net> Envelope-to: ed@membled.com Delivery-date: Sat, 15 Sep 2001 12:29:37 +0100 Received: from [146.169.1.46] (helo=duck.doc.ic.ac.uk ident=exim) by falcon.doc.ic.ac.uk with esmtp (Exim 3.13 #8) id 15iDdh-00021s-00 for ed@membled.com; Sat, 15 Sep 2001 12:29:37 +0100 Received: from cj635608-a.reston1.va.home.com ([65.1.136.101] helo=bloatware.dickey.net) by duck.doc.ic.ac.uk with esmtp (Exim 3.16 #7) id 15iDdh-0002Wq-00 for ed@membled.com; Sat, 15 Sep 2001 12:29:37 +0100 Received: (from tom@localhost) by bloatware.dickey.net (8.9.3/8.9.3/Debian 8.9.3-21) id HAA00490 for ed@membled.com; Sat, 15 Sep 2001 07:33:57 -0400 Date: Sat, 15 Sep 2001 07:33:57 -0400 From: Thomas Dickey <dickey@herndon4.his.com> To: Edward Avis <ed@membled.com> Subject: Re: xterm bug: background colour wrong after scrolling Message-ID: <20010915073357.A442@invisible-island.net> Reply-To: dickey@herndon4.his.com References: <Pine.LNX.4.21.0109151148200.23488-100000@project04.doc.ic.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.LNX.4.21.0109151148200.23488-100000@project04.doc.ic.ac.uk>; from ed@membled.com on Sat, Sep 15, 2001 at 12:01:22PM +0100 Status: RO X-Status: A X-Keywords: X-UID: 246 On Sat, Sep 15, 2001 at 12:01:22PM +0100, Edward Avis wrote: > (I have read the xterm FAQ and I don't think this bug is the same as > 'background color is not reset'. I reported this on the XFree86 site > ten months ago, but I can't find any trace of my bug report so I'm > resending it to you directly in case it got lost.) > > It is easier to show the files to reproduce this bug than to explain it > in words: please have a look at > <http://membled.com/work/bugs/xterm/>. The colours get > reset back to black on white, but then after the end of the printed text > the background reverts back to red. What is odd is that this happens > only after the xterm window has scrolled. If you open a new xterm and > do not scroll it, the results are what I'd expect. yes - I haven't visited this one for a while, but essentially what happens is that the color in effect for fill when doing a scrolling operation is the current ANSI color. I have a couple of test cases. I've also seen this effect with Linux console and a couple of other emulators. (At one time, I started a patch to make different aspects of the background color optional, so I could experiment with different schemes, but I didn't finish that). -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net From tom@invisible-island.net Sat Sep 15 18:35:51 2001 Return-path: <tom@invisible-island.net> Envelope-to: ed@membled.com Delivery-date: Sat, 15 Sep 2001 18:35:51 +0100 Received: from [146.169.1.47] (helo=diver.doc.ic.ac.uk) by falcon.doc.ic.ac.uk with esmtp (Exim 3.13 #8) id 15iJM7-0003jI-00 for ed@membled.com; Sat, 15 Sep 2001 18:35:51 +0100 Received: from cj635608-a.reston1.va.home.com ([65.1.136.101] helo=bloatware.dickey.net) by diver.doc.ic.ac.uk with esmtp (Exim 3.16 #7) id 15iJM6-000631-00 for ed@membled.com; Sat, 15 Sep 2001 18:35:50 +0100 Received: (from tom@localhost) by bloatware.dickey.net (8.9.3/8.9.3/Debian 8.9.3-21) id NAA09727 for ed@membled.com; Sat, 15 Sep 2001 13:40:03 -0400 Date: Sat, 15 Sep 2001 13:40:03 -0400 From: Thomas Dickey <dickey@herndon4.his.com> To: Edward Avis <ed@membled.com> Subject: Re: xterm bug: background colour wrong after scrolling Message-ID: <20010915134003.A9712@invisible-island.net> Reply-To: dickey@herndon4.his.com References: <20010915073357.A442@invisible-island.net> <Pine.LNX.4.21.0109151249510.23827-100000@project04.doc.ic.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.LNX.4.21.0109151249510.23827-100000@project04.doc.ic.ac.uk>; from ed@membled.com on Sat, Sep 15, 2001 at 12:59:05PM +0100 Status: RO X-Status: X-Keywords: X-UID: 247 On Sat, Sep 15, 2001 at 12:59:05PM +0100, Edward Avis wrote: > >><http://membled.com/work/bugs/xterm/> > > >essentially what happens is that the color in effect for fill when > >doing a scrolling operation is the current ANSI color. > > Ah, so the new line at the bottom of the terminal is first drawn using > the current background colour (which happens to be red, since it was set > to red in the previous line), and then the actual content of the line is > printed. But since the content is less than a full line width, it > doesn't fully overwrite the solid red that was drawn on scrolling. yes - as the screen is shifted up by one line, the new area is cleared with the red color. > That explains why this bug occurs only with a narrow enough terminal > window to make the red text spill over from one line to the next. > > I see now that it occurs when the text being printed causes the window > to scroll, not 'when the xterm has been scrolled in the past' as I > originally thought. right > I guess the fix would be to not fill the newly created line with > anything, but just print text to it and fill the remainder of the line > (if any) with the new background colour. But you'll know more about > this stuff than me. > > Thanks for your response. If you don't mind, I'll make it into a Web > page documenting this bug. no problem > >I've also seen this effect with Linux console and a couple of other > >emulators. > > So is it a deliberate feature, or just a very common mistake? I haven't decided if it's an unavoidable consequence of the other aspects of clearing with the current background color, or whether there's a special case that can be factored out. (Bear in mind that this also has to work consistently with curses libraries that only know if the terminal clears with the background color or not). There're several types of clearing going on in the terminal emulation - offhand: - clearing the whole display (includes clearing from the cursor to either end of the screen) - clearing the current line (likewise, includes clearing from the cursor to either end of the line) - shifting/scrolling (indexing actually) - insert/delete character in the current line As I said, I did start a patch at one point (but got distracted with some more urgent issue) to allow any of those features to be individually enabled. That would for instance let me customize xterm to match the behavior of some related programs (scoterm, aixterm, dtterm), by just setting appropriate resources. -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net