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 dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature