Re: PATCH and Re: simulation of dabbrev-expand

[Adam Spiers <adam@xxxxxxxxxxxxxxxxxxxxxxx>]

Sven Wischnowsky (wischnow@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> 
> [ Trying to reduce the number of replies by answering multiple
> messages... ]

Welcome back to the fun :-)

> First, the `design decision' comes from a time when one couldn't
> execute shell code (and look at the current state) during
> completion. Then, I think it is still right to execute the probably
> expansive sorting and uniquifying as seldom as possible -- and in most 
> cases this is really only needed at the end. But I after thinking some 
> more about this, I really think, the solution to do the calculation
> when one of the `nmatches' keys is used is ok.

Yep, this should be fine I guess.

> ...by adding a key, say `list_lines' or whatever which would allow us
> to write shell code that can find out if the listing code would ask
> (well, of course we could also check this in C and have a key saying
> whether it would ask, but that check is easy and knowing the number of 
> lines may be intersting anyway, maybe, hm...). Anyway, with the
> relatively new `calclist()'  this would be quite easy to implement
> (heck, we could give many different types of information about the
> list).

That would be nice too.  Then you could be quite intelligent about
what to display.  For example you might want to specify LIST_MAX as
multiples of the screen length.

> > Selecting completion groups would be a nice feature in any case.
> 
> This is something I want to achieve (see 12241, at least if I
> understand you correctly) with the grouping anhancements to the
> completion system discussed lately (keywords: tags, priorities, and
> Peter's auto-documentation suggestion).

I look forward to it :-)