Re: simulation of dabbrev-expand

[Adam Spiers <adam@thelonious.new.ox.ac.uk>]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> 
> Adam Spiers wrote:
> 
> > [ removing duplicates in completion lists ]
> > 
> > I think it should be optional.  I also think you should have the
> > choice of whether to remove all duplicates or just consecutive ones.
> > What about -1 and -2, or some other funny option characters?
> 
> Ok. This makes `-1' keep the completion system from removing all
> duplicates and `-2' keep it from removing consecutive duplicates. Yes, 
> the sense is reversed so that `-J' still gives the normal behaviour.

Nice work, Sven!  The potential for an almost perfect
_history_complete_word is now upon us ... although I'm having problems
creating it.

The current situation is that _history_complete_word crawls through
matching history words, oldest first.  This is counter-intuitive,
impractical, and not what tcsh users would expect; so I've been
trying to change it to the following setup:

   M-/  _reverse_history_complete_word
   M-,  _history_complete_word

_reverse_history_complete_word startest with the most recent match and
works back, and vice versa for _history_complete_word.

However, I got stuck when handling the history_stop feature.
When in verbose mode, history_stop uses _message to indicate that the
beginning/end of the history has been reached.  However, unless I've
got things really wrong, _message seems to destroy any old list of matches
which you might want to keep.  I can't understand why, as it's only
essentially a compadd -X ... -n ''.  I want to do something like:

    compstate[old_list]=keep
    _message 'beginning of history reached'

so that if you hit the oldest match and press M-/ again, it displays
this message but keeps the oldest match (should I need a
compstate[insert]=1 again, or is it enough to have done that the first
time the oldest match was displayed?), and if you switch to M-, it
will keep this old_list again and start moving in the opposite
direction.

Finally, should forward and reverse motion both be handled by the same
widget?

If you can help with the above problem then with luck I'll be able to
save you the hassle of rewriting all the code.  Thanks!

Adam