"xterm -si" doesn't hold the line
Sat Jul 28 15:57:00 GMT 2012
On Sat, Jul 28, 2012 at 02:49:22PM +0200, Paul Maier wrote:
> 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):
True: scroll to bottom when tty receives output; option -si.
False: do not scroll to bottom when tty receives output; option
However, rxvt (also long ago) implemented a different flavor:
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.
Thomas E. Dickey <email@example.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the Cygwin-xfree