From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24676 invoked by alias); 28 Jul 2012 15:57:55 -0000 Received: (qmail 24664 invoked by uid 22791); 28 Jul 2012 15:57:53 -0000 X-SWARE-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,BAYES_20,BOTNET,HDRS_LCASE,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_RX X-Spam-Check-By: sourceware.org Received: from vms173007pub.verizon.net (HELO vms173007pub.verizon.net) (206.46.173.7) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 Jul 2012 15:57:38 +0000 Received: from par-debian50-32.jexium-island.net ([unknown] [96.255.140.153]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M7V002CQOBSW490@vms173007.mailsrvcs.net> for cygwin-xfree@cygwin.com; Sat, 28 Jul 2012 10:57:32 -0500 (CDT) Received: from par-debian50-32.jexium-island.net (localhost [127.0.0.1]) by par-debian50-32.jexium-island.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6SFvRsv025121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Jul 2012 11:57:27 -0400 Received: (from tom@localhost) by par-debian50-32.jexium-island.net (8.14.3/8.14.3/Submit) id q6SFvRah025119; Sat, 28 Jul 2012 11:57:27 -0400 Date: Sat, 28 Jul 2012 15:57:00 -0000 From: Thomas Dickey To: Paul Maier Cc: cygwin-xfree@cygwin.com, dickey@his.com Subject: Re: "xterm -si" doesn't hold the line Message-id: <20120728155726.GA25043@debian50-32.invisible-island.net> Reply-to: dickey@his.com References: <000001cd6cbf$6a0c8090$3e2581b0$@de> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=zhXaljGHf11kAtnf Content-disposition: inline In-reply-to: <000001cd6cbf$6a0c8090$3e2581b0$@de> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2012-07/txt/msg00027.txt.bz2 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3714 On Sat, Jul 28, 2012 at 02:49:22PM +0200, Paul Maier wrote: > Hi, >=20 > 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 autom= at- ically cause the scrollbar to go to the bottom of the scroll= ing 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. =20 and (relatively recently - two years ago) I implemented a different choice: allowScrollLock (class AllowScrollLock) Specifies whether control sequences that set/query the Scr= oll Lock key should be allowed, as well as whether the Scroll L= ock 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 t= og- gling the associated LED. While the Scroll Lock is acti= ve, 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 u= ser surprise. This key is generally unused in keyboard configu= ra- 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): >=20 > 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 >=20 > You see: xterm scrolls slowly down. >=20 > I would expect xterm to hold the current view while xev produces more lin= es at the end. >=20 >=20 > Suppose you have a "tail -f" running and scroll the xterm up to view a sp= ecific 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 dow= n line by line, > as if xterm would try to keep the same distance between the current scrol= ling position and the most recent line. >=20 > I would expect xterm to keep the same distance between the current scroll= ing position and the *FIRST* line. >=20 >=20 > In case above behaviour is the desired behaviour, I wanted to suggest ano= ther command line option like "-si-top" > for my use case. >=20 > Regards, > Paul >=20 --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline Content-length: 197 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlAUC+YACgkQcCNT4PfkjttRzQCdEzG99aqpVtPnULekJG4aV8BC 84UAn33uGJ3HpgLOiV6e9rQY7yXiYGtQ =KwHX -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--