RE: completion with globbing, take 2

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

>
> On Sep 18, 10:53am, Andrej Borsenkow wrote:
> } Subject: RE: completion and globbing, part 2
> }
> } Well, what you've effectively done is to write stripped-down version of
> } _match :-)
>
> Not quite; he's written a stripped-down version of "_expand with the
> completions style defaulted to true, followed by _match".
>

I tentatively disagree. The main difference between _expand and _match is who
generates matches. Completion aside, _expand generates "matches" (that are
actually expansions in this case) itself. _match takes all possible
completions and tries to match them against given pattern. See the difference?
To write stripped-down version of _expand means something like (for globbing
only)

foo=($~CURRENT)
compadd -- "$foo"

As I wrote, it is just a coincidence that file completion is using the same
pattern from command line, hence _expand and _match look alike.

BTW thank you all for finally making it clear to me :-)))

> } Could you consider patching _match adding a style to control it?
>
> The most obvious thing would be to have _match itself recognize the
> completions style.
>

Is is not enough. See later.

> } But _match just modifies behaviour of subsequent completer ...
>
> Eh?  It *calls* _complete.  How is that modifying subsequent completers?
>

Eh ... I meant that, actually. I had in mind this difference between _expand
and _match as described above.

>
> You have to remember to provide the standard completion-system setopts
> in any wrapper around the supplied completer functions.
>
>  _insert_all_matches () {
>      setopt localoptions nullglob rcexpandparam extendedglob noshglob
>      unsetopt markdirs globsubst shwordsplit nounset ksharrays
>      compstate[insert]=all
>      compstate[old_list]=keep
>      _complete
>  }
>
> (Speaking of which, there's nullglob in the list.  Who was it who added
> (N) to all those glob patterns in several functions?)
>

Sven in zsh-workers/12768

> } But, as stated, it has all sorts of problems. It does not work
> correctly after
> } *completion* - it tries to complete word already inserted (that is, it is
> } treated as new completion instead of continuation of old - but this may be
> } related to my styles settings).
>
> Hmm ... can you give an example of what you see that you think is wrong?
> It seems OK to me (and I'm curious which of your styles might botch it).
>

I had in mind interaction between _oldlist and _match. When you have a pattern
and press TAB first time, you get a list. When you press TAB second time,
completion system tries to reuse this old list instead of taking current word
and trying to complete it (assuming proper style setup - but, may be, it is
even default). So, somehow I expected currently inserted word to be replaced
with all matching completions (and compstate[oldlist]=keep was exactly for
that). But I am not even sure, if it possible.

O.K. about adding completions style to _match. Note, that if completions style
is set for _expand it just calls _complete. If it generated any matches,
_expand just exits. If no matches were generated, it does it itself and now
has full control over possible tags.

But what we actually need, is to get completions that _complete just
generated, together with all tags, descriptions and whatever else, and add to
them e.g. "all matches" tag. And that while preserving all user settings for
verbose, tag ordering etc etc etc. Something like

compstate[pattern_match]=\*
  if _complete; then
     if _requested all-matches ...
     then
        all_matches=??? # gets all generated matches
        compadd ... -- "$all_matches"
     fi
   fi

Hmm ... actually, quite possible. Assuming, that we can get all matches.

-andrej