Re: "xterm -si" doesn't hold the line

[Thomas Dickey <dickey@his.com>]

[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]

On Sat, Jul 28, 2012 at 02:49:22PM +0200, Paul Maier wrote:
> Hi,
> 
> xterm -si doesn't work as expected.

The short answer is that it's always been that way :-)

This refers to the scrollTtyOutput, which in xterm is described:

       scrollTtyOutput (class ScrollCond)
               Specifies whether or not output to the terminal should automat-
               ically cause the scrollbar to go to the bottom of the scrolling
               region.  The default is ``true.''

and in rxvt (in the mid-1990s):

       scrollTtyOutput: boolean
           True: scroll to bottom when tty receives output; option -si.
           False: do not scroll to bottom when tty receives output; option
           +si.

However, rxvt (also long ago) implemented a different flavor:

       scrollWithBuffer: boolean
           True: scroll with scrollback buffer when tty receives new lines
           (and scrollTtyOutput is False); option -sw. False: do not scroll
           with scrollback buffer when tty receives new lines; option +sw.
 
and (relatively recently - two years ago) I implemented a different choice:

       allowScrollLock (class AllowScrollLock)
               Specifies  whether  control sequences that set/query the Scroll
               Lock key should be allowed, as well as whether the Scroll  Lock
               key responds to user's keypress.  The default is "false".

               When this feature is enabled, xterm will sense the state of the
               Scroll Lock key each time  it  acquires  focus.   Pressing  the
               Scroll Lock key toggles xterm's internal state, as well as tog-
               gling the associated LED.  While the  Scroll  Lock  is  active,
               xterm attempts to keep a viewport on the same set of lines.  If
               the current viewport is scrolled past  the  limit  set  by  the
               saveLines resource, then Scroll Lock has no further effect.

               The  reason for setting the default to "false" is to avoid user
               surprise.  This key is generally unused in keyboard  configura-
               tions,  and has not acquired a standard meaning even when it is
               used in that manner.  Consequently, users have assigned it  for
               ad hoc purposes.

That has the same general effect if Scroll Lock is set - I might still
add a "-sw" option like rxvt.

> To reproduce (think of a "tail -f" instead of xev):
> 
> 1. xterm -si -e /bin/xev
> 2. move the mouse in the xev window to produce some lines
> 3. scroll the xterm up half way and remember the visible lines
> 4. while looking at the xterm, again move the mouse in the xev window
> 
> You see: xterm scrolls slowly down.
> 
> I would expect xterm to hold the current view while xev produces more lines at the end.
> 
> 
> Suppose you have a "tail -f" running and scroll the xterm up to view a specific line.
> I would expect that line to stay visible until I scroll somewhere else.
> But it's not: as the "tail -f" produces output, the xterm scrolls slowly down.
> To clarify: xterm does not scroll down to the very end but it scrolls down line by line,
> as if xterm would try to keep the same distance between the current scrolling position and the most recent line.
> 
> I would expect xterm to keep the same distance between the current scrolling position and the *FIRST* line.
> 
> 
> In case above behaviour is the desired behaviour, I wanted to suggest another command line option like "-si-top"
> for my use case.
> 
> Regards,
>   Paul
> 

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]