From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <3.0.5.32.20000930040229.00adfd20@mail.real.com>
Date: Sat, 30 Sep 2000 04:02:29 -0700
To: 9fans@cse.psu.edu
From: Skip Tavakkolian <skipt@real.com>
Subject: Re: [9fans] Adding history to Rio's windows
In-Reply-To: <009e01c02a8c$6498d6e0$97036887@cs.belllabs.com>
References: <3.0.5.32.20000928160709.00ac9100@mail.real.com>
 <3.0.5.32.20000928214826.00ada630@mail.real.com>
 <006f01c02a56$0b820bc0$89c584c3@cybercable.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Topicbox-Message-UUID: 1317c4e4-eac9-11e9-9e20-41e7f4b1d025

After reading the discussions here, I am coming around to your point of view.

Has anything like this next idea been considered?
Use 'pipefile' and a pair of cooperating filters to interpret some
keyboard input as scrolling through the input history. The output
filter would supply the history item.

At 10:30 PM 9/29/00 -0400, rob pike wrote:
>I'm of two minds on this topic.  It's nice to make it easy to redo commands,
>but I've never seen a suggested design, including this one, that feels
>easy enough to beat a simpler, less invasive keyboard-driven history
>mechanism. Muck up the button 2 menu and you'll have a lot to answer
>for.  It might be worth trying, but be honest with the result, and toss it
>if the gain isn't worth the cost in menu navigation.  You *will* make cut
>and paste harder to use.  I agonized about adding "plumb" to the button
>two menu, and finally decided to do it because it provided something
>entirely new.  There are other ways to provide history, however.
>
>-rob
> 
>
>
>