From owner-freebsd-hackers  Fri Jan 10 14:12:04 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id OAA06191
          for hackers-outgoing; Fri, 10 Jan 1997 14:12:04 -0800 (PST)
Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA06174
          for <freebsd-hackers@freebsd.org>; Fri, 10 Jan 1997 14:11:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by chai.plexuscom.com (8.8.4/8.6.12) with SMTP id RAA13433; Fri, 10 Jan 1997 17:11:57 -0500 (EST)
Message-Id: <199701102211.RAA13433@chai.plexuscom.com>
X-Authentication-Warning: chai.plexuscom.com: localhost [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
Cc: gilham@csl.sri.com (Fred Gilham), freebsd-hackers@freebsd.org
Subject: Re: A cool xterm? 
In-reply-to: Your message of "Fri, 10 Jan 1997 13:14:39 MST."
             <199701102014.NAA20438@phaeton.artisoft.com> 
Date: Fri, 10 Jan 1997 17:11:57 -0500
From: Bakul Shah <bakul@plexuscom.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> NextStep has the increment up/down adjacent to each other; that is a
> big, big win in my book; I don't have to move the mouse pointer
> across nearly as much realestate to change direction if I overshoot
> by one line while scrolling.

In the scrollbar used in `ups' (the debugger), the distance you drag
the cursor determines the *velocity* of scrolling: move the cursor
*anywhere* in the scrollbar window; press the left button and drag
the cursor up or down.  The farther you drag it, the faster the
window scrolls.  When you get close to the target, you can drag back
towards the original position and scrolling can be slowed down to a
crawl.  If you overshoot, move past the original position to scroll
in the opposite direction.  This is much like a single dial for fast
forward/reverse button on some VCRs.  Very handy.

A similar scheme for selecting text would be nice.

> I think the riginal complaint was that cleared screens did not get added
> as complete units to the scrollback buffer of xterm.

Yeah, this would be better but can be somewhat confusing.  Perhaps
a thin horizontal line should separate screens cleared this way.

Also, there should be a way to dump lines to a file (on command) as
well as increase/decrease line buffer size.