PATCH and Re: simulation of dabbrev-expand

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

First: there was a buglet in `_history_complete_word' which made it
pretty useless if `history_stop' wasn't set. I hope the patch below
doesn't interfere with your work...

Adam Spiers wrote:

> The current situation is that _history_complete_word crawls through
> matching history words, oldest first. 

Now I'm confused. For me it works from the bottom up. *But* words
from the same line are inserted left-to-right. Since the C-code walks
up maybe we should add the words from the end of the line to the
beginning.

We should then use the hunk for `zle_tricky.c' below.

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

... but a `_reverse_*' would still be good to have (I thought about
this when I made my last changes to `_h_c_w' but was to lazy...).

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

That's right. To be able to display the message we have to add a dummy 
completion (that empty string) and throw away the old list.

> I want to do something like:
> 
>     compstate[old_list]=keep
>     _message 'beginning of history reached'

This can't work and I don't think it should. Since the `messages' are
really only explanation string they belong to their own list and
should only be displayed when that list is used.

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

If I were to implement that, I would use two (global) parameters set
when the end is reached with `verbose' (or always when the end is
reached). Any of the two ends, that is. The first parameter just says
that the end was reached (and could say which end if that is
needed). The other one would contain the value of `BUFFER' at the time 
the end was reached. Now if you invoke the widget for the other
direction when an end was reached (the first parameter sayeth so), you 
compare the second parameter with the current value of `BUFFER'. If
they are equal, the thing was just invoked (hm, maybe we shouldn't
compare `BUFFER', maybe we should check `LASTWIDGET'; or both; and if
you use the numeric argument thing, the latter may also need to have
to take that into its calculation). Anyway, the test would say that we 
just reached one of the ends by the history_complete function for the
other direction and if we find that out, we just call completion again 
(that `compgen') and then use `compstate[insert]=-1' (or `...=1' for
the other direction). Getting words to complete from the history
should be fast enough so that the user doesn't really notice that a
new list was created. For this we would also have to keep the original 
values of `PREFIX' and `SUFFIX' -- and set them anew in the right
place.

Anyway, I think it can be done...

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

Shrug, dunno. The builtin widgets always have two forms and use the
numeric argument (and use the other direction if that is negative)...

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

I hope it helped.

Bye
 Sven

diff -u oldcompletion/Commands/_history_complete_word Completion/Commands/_history_complete_word
--- oldcompletion/Commands/_history_complete_word	Tue Sep 21 10:26:40 1999
+++ Completion/Commands/_history_complete_word	Thu Sep 23 10:14:42 1999
@@ -23,8 +23,8 @@
     _description -V expl 'history word'
   fi
   compgen "$expl[@]" -Q -H 0 ''
-  compstate[insert]=1
   if [[ -n "$compconfig[history_stop]" ]]; then
+    compstate[insert]=1
     _hist_menu_length="$compstate[nmatches]"
     _hist_menu_end=''
   fi
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Sep 23 10:19:05 1999
+++ Src/Zle/zle_tricky.c	Thu Sep 23 10:21:09 1999
@@ -6932,7 +6932,7 @@
 	/* Now search the history. */
 	while (n-- && he) {
 	    int iwords;
-	    for (iwords = 0; iwords < he->nwords; iwords++) {
+	    for (iwords = he->nwords - 1; iwords >= 0; iwords--) {
 		h = he->text + he->words[iwords*2];
 		e = he->text + he->words[iwords*2+1];
 		hpatsav = *e;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de