Re: PATCH and Re: simulation of dabbrev-expand

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

[ Trying to reduce the number of replies by answering multiple
messages... ]

Adam Spiers wrote:

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

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. Normally we do this at
the very beginning (so there are no matches and this doesn't take any
time) and at the end (and then we still do the work only once because
the stuff calculated when `compstate[nmatches]' was used at the end).

This could also be combined with...

Benjamin Korvemaker wrote:

> 2) When there are too many completions, and a prompt like
> 
> zsh: do you wish to see all 102 possibilities? 
> 
>    shows up, can I simply get it to:
>     a) not prompt,
>     b) not list, and
>     c) maybe say "**lotsa completions - not listing**"
> 
> Thanks for the help!

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

Adam Spiers wrote:

>       d) list the completion groups and the number of matches in each,
>          and then let you choose which group to complete from.
> 
> Selecting completion groups would be a nice feature in any case.
> 
> I might have a go at hacking some of these, but will probably fail and
> have to wait for Sven to get back.  I'm away this w/e myself, however.

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

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx