[9fans] Adding history to Rio's windows

[9fans] Adding history to Rio's windows

[Skip Tavakkolian]

History of 'history': The rc script that Russ Cox posted a while back
(named " and attributed to Killian) performs the function for what I am
proposing here. This is a raw idea for supporting it in Rio.

The UI part is similar to how Sam keeps previously searched for patterns
in the menu; It is not "history" in the shell sense (the last n commands),
but a list that keeps the last n snarf buffers that have been sent to the
process using the middle button menu's 'send' command. Like so:

+----------+
| cut      |
| paste    |
| snarf    |
| plumb    |
| send     |
| scroll   |
|~~~~~~~~  |
| grep -.. |
+----------+

If a history item is selected, it is assumed that the user wants 'send' it
(or should it be 'paste'?).
Is this sane?

Re: [9fans] Adding history to Rio's windows

[Boyd Roberts]

ooh, i have a feeling of cascading menus -- gag.

Re: [9fans] Adding history to Rio's windows

[Skip Tavakkolian]

>ooh, i have a feeling of cascading menus -- gag.

Cascading menus wont be necessary. The history
items would be appended to the bottom of the middle-button menu.
This is analogous to how the labels of hidden windows
appear in the bottom of the right-button menu.

Re: [9fans] Adding history to Rio's windows

[Boyd Roberts]

From: "Skip Tavakkolian" <skipt@real.com>

> Cascading menus wont be necessary. The history
> items would be appended to the bottom of the middle-button menu.
> This is analogous to how the labels of hidden windows
> appear in the bottom of the right-button menu.

exactly what i suggested to rob, many years ago, so that the window manager
worked like sam did; all windows accessible on button 3.  i'd suggested an
ioctl(), to name the windows, but then came along /dev/label.  good thing
ioctl died and ctl files replaced that machine dependent junk.

as i recall, rc used to write a history file, like the 8th ed shell.  the
code
got taken out 'cos no-one used it.  i'm not sure that the window system
should be trying to grok the input/output to work out whether it's a
history thing.

perhaps there's a better approach?

Re: [9fans] Adding history to Rio's windows

[rob pike]

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
 

Re: [9fans] Adding history to Rio's windows

[Skip Tavakkolian]

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
> 
>
>
>

Re: [9fans] Adding history to Rio's windows

[Scott Schwartz]

A clean way to do history would be to have the window system tag each bit
of text with a set of tokens.  You'd want a token for user input, a token
for program output, and probably also tokens for font, size, and color.
Given that, an external history command could figure out what the last
user input was directly, instead of having to grep for the prompt in a
text buffer.  (The Tk text widget is a working example of such a thing.)

[9fans] Adding history to Rio's windows

[Richard Uhtenwoldt]

Skip Tavakkolian writes:
>History of 'history': The rc script that Russ Cox posted a while back
>(named " and attributed to Killian) performs the function for what I am
>proposing here. This is a raw idea for supporting it in Rio.
>
>The UI part is similar to how Sam keeps previously searched for patterns
>in the menu; It is not "history" in the shell sense (the last n commands),
>but a list that keeps the last n snarf buffers that have been sent to the
>process using the middle button menu's 'send' command. Like so:
>
>+----------+
>| cut      |
>| paste    |
>| snarf    |
>| plumb    |
>| send     |
>| scroll   |
>|~~~~~~~~  |
>| grep -.. |
>+----------+


If I understand correctly, even without the " and "" commands, the user
already has access to the historical inputs: namely, the user can scroll
backwards in the Rio window (aka, text buffer) and, as soon as the
desired input becomes visible, can select it with the mouse and resend
it.  the difficulty is that the historical inputs are interleaved with
many lines of historical outputs, making the inputs tedious to search
through.  one way to ease that tedium would be a command that toggles
the Rio window into a state in which only inputs are displayed (and thus
searching through the inputs is easier).

ie, the commands cause Rio's "redisplay routine" to omit
displaying historical outputs.

Re: [9fans] Adding history to Rio's windows

[Russ Cox]

I think " and "" are easier to use, especially since you
can quickly specify which command you want.  Also, if you
don't use the prompt, how do you tell user input to
the shell from input to another program?  I quite like
the blur actually: I make lists of commands prefixed
with g% and cat them in windows to ``seed'' the behavior
of " and "".

There seem to be good arguments that five is
about the most number of things that is comfortable
on a menu.  For more see the bottom of p. 7 of
http://cm.bell-labs.com/cm/cs/doc/88/1-07.ps.gz.
I have a hard time finding things quickly in the button 2
menu now that "plumb" makes six items.
Hiding windows makes the same thing happen on the
button 3 menu.  For a good time, try navigating a >200
page PDF file using page's button 3 menu.

Russ

Re: [9fans] Adding history to Rio's windows

[Scott Schwartz]

| Also, if you
| don't use the prompt, how do you tell user input to
| the shell from input to another program?

Hm.  Well, if one process had a way to find out which
other one did a write(), it could record that too.
That's a facility that's generally useful, in fact.

| There seem to be good arguments that five is
| about the most number of things that is comfortable
| on a menu.

That's true of a linear menu.  Radial pie menus comfortably support
many more items, and you can use them without looking.  Imagine a clock
(12 items) or a compass (8 items), for example.

| For a good time, try navigating a >200
| page PDF file using page's button 3 menu.

Yep.  Unbounded and variable entries are the wrong thing for
menus.

Re: [9fans] Adding history to Rio's windows

[Boyd Roberts]

From: "Russ Cox" <rsc@plan9.bell-labs.com>

> There seem to be good arguments that five is
> about the most number of things that is comfortable
> on a menu

yes, reminds me of the 7 + or - 2 'things' study used to work out
how may 'things' people could remember.  it was used to decide
on 7 digit phone numbers for the bell system -- most people
can remember 7, some can only remember 5, and others can
remember 9.

sam becomes pretty unmanageable when you have 20 (or so) windows.
the menu is just too big, the 'scrollbar' menu was hard to use 'cos wherever
you were was always a long way from where you wanted to be and the
mouse manipulation was unpleasant.