Re: PATCH and Re: simulation of dabbrev-expand

[Adam Spiers <adam@xxxxxxxxxxxxxxxxxxxxxxx>]

Sven Wischnowsky (wischnow@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> [ Last mail from me for the next two weeks... ]

:-(

> >   - Whenever duplicates get removed, it breaks.  It looks like
> >     compstate[nmatches] corresponds with the number of matches
> >     /including/ duplicates, even if some/all duplicates have been
> >     removed.
> 
> At the time where you can look at `compstate', it is `...will be
> removed'. Remember that all the sorting and uniquifying is only done
> after the widget has returned (and for performance reasons we should
> probably only do it then).

Hmm.  This really is a problem.  Anything which wants full control of
menucompletion (and hence implements it itself, e.g. _history_complete_word,
which wants the ability to stop at either end of the matches) will need to
know an accurate compstate[nmatches] straight after the compgen call.
What's the correct solution here?  It would be nice if the C code
implemented loop prevention (it feels kind of hacky doing it all through
messing around with compstate[insert]) but it's difficult to draw the line
between what should be in the C code and what should be shell script ... for
example you might want control over what message (if any) should be
displayed when you hit one of the ends of the list of matches.

Any ideas on what's the Right Way here?

One workaround would be to ensure that whenever compstate[oldlist] is set to
`keep', compstate[nmatches] is set to the size of the old list.  That way,
in the _history_complete_word case, you could recalculate nmatches
accurately on the second call to the widget, which would be good enough.

> Although... we could do it whenever someone 
> looks at `compstate[*nmatches]', set a flag if the list is sorted and
> clear the flag when another match is added. Hm. No time now...

Sounds reasonable, but still feels (IMO) a bit of a workaround forced by the
wrong design decision.  Maybe there's no good solution.  *shrug*