> Yes

> I think that part of the problem is that we are hanging up on the
> "insert mode" paradigm, which is already broken by the way that
> history (and TAB in some promts) is handled.

> In normal (insert) mode, a history item or a TAB selection should never
> replace what the user has already typed. I brought this up recently with
> regard to TAB in filespec.

> If I explicitly type XYZ and then pull up history and select an item, that
> SHOULD NOT replace what I had already typed, the current mode essentially
> suggests that I did not know what I was doing when I was typing XYZ.

> If there is a highlight, then the TAB or history selection should replace
> that highlight. Otherwise, it should really be in insert mode (the most
> common case is actually append to the end of the current string because
> the cursor is probably at the end. Also, note that ZTree does provide a
> user highlighting function already in prompts using the standard
> shift-left/right/etc paradigm.

> So, here is what I propose. This may require another YACO much like
> spell-search did because it does change historical behaviour, but my guess
> is that most of us would turn it on quickly and leave it on because it
> does not actually change what we type in in most cases:

> 1) Default mode is "insert" (as it is currently).
> 2) Mode can be toggle (as currently) with the Insert key
> 3) Highlighting does not change, including the ablity to set one using
> shift-cursor keys
> 4) In insert mode, a selection from history (or via TAB) replaces any
> highlight text with the item, highlighting the replacement text as well
> (this allows TAB cycling, maybe should not apply to history selections).
> If there is no highlight, it inserts the history/TAB item at the cursor
> position -- Again, for at least TAB cycling, TAB items should be
> highlighted.
> 5) Using shift-Up or shift-Down to enter the history list has the effect
> of highlighting everything in the current prompt string. Currently these
> keystrokes have no effect except to clear a highlight if there is one (and
> sometimes delete it and sometimes not), and the Delete key is certainly
> sufficient for this.
> 6) As an extension for item (5), shift-Up and shift-Down also move the
> cursor in the history list to the first item in the history (in the
> appropriate direction) that matches the typed value like spell-search
> (i.e., prefix, or possibly as a substring anywhere in the history item
> since a lot of items start with something like C: or the like)). While in
> history, a further shift-Up/Down jumps to the next item that matches. In
> other words, typing AB and then shift-Up would find items like ABCD and
> ABXY but not XYCD or NPOQ. The result of that would be quicker navigation
> of history lists. This part might require some work on Kim's part but not
> a lot...
> 7) Shift-ctrl-% and shift-alt-% selection from history would have the
> current effect of completely replacing the prompt string regardless of the
> insert mode.
> 8) If not in "insert" mode, then a history/TAB selection should
> either overwrite (as if typed) or do a full replacement -- Open to debate,
> but I tend to think overwrite is the better choice.

> Yes, there are extra keystokes defined, but they are internally consistent
> and would quickly become natural...

Agree, other than the key ends up different to spell search and other places that cycle through a list.

Proposed history: Shift-Up/Down
Active Spell search: Shift-2 (")
Propmted Spell search: PgUp/PgDn
Various palces: [Shift/Ctrl-]Tab

I would prefer a reduction of the numbers of ways to cycle through matches, wherever posible, so that only one or two ways need to be remembered, this would make ZTree easer for new users to learn and make the interface more intuitive.

I think that [Shift-]Tab should be used wherever posible, then PgUp/PgDn or Shift-PgUp/PgDn, and if possible Shift-PgUp/PgDn should allways work, then you could just use Shift-PgUp/PgDn everywhere.

Ben