Re: Bug in completion with curly braces?

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> Consequently if the calling function does not apply quoting, -Q is
> only going to work well in cases where the matches either have no
> common prefixes, or the common prefixes do not contain any of the
> special characters, or menu completion is going to be forced (so the
> user selects an entire match all at once rather than exit/re-enter
> completion with the prefix).
>
> (I would be happy to have someone (Oliver?) argue the untruth of that
> last statement.)

I think it is essentially true except that your list of three special
cases can perhaps be expanded. To say it doesn't "work well" perhaps
misrepresents that it does do something well-defined, just not
especially useful when misused.

If you search for compadd.*-Q in completion functions, the cases are not
normal. It is often combined with -U which disables matching altogether.
You'll see cases where $PREFIX was used in building the actual values
passed to compadd. Cases where compquote has been used first. And where
QIPREFIX is checked. And anything that looks normal is probably wrong,
e.g. in _gdb.

I've been assuming that in Felipe's case, he is forced to use -Q because
that is what bashcompinit does. bashcompinit uses it because of a patch
he submitted in 30136 to make it do so. At the time, I wasn't motivated
to review it but can remember being somewhat skeptical. Looking in more
detail now, it is correct in essence but it doesn't surprise me that it
should also cause some unexpected issues.

Looking at the bash example in 30136, it would appear that quoting
is left up to the completion function. Is that always true for bash
completions? Matches are added with an unquoted trailing space but also
some quoted spaces. To get it to pass through compgen, it seems two
levels of quoting and removing space from IFS was necessary. Is this
idiom common?

We could do something like the following in bashcompinit to special case
only space suffixes:

-      compadd -Q "${suf[@]}" -a matches && ret=0
+      compadd "${suf[@]}" - "${(@)${(Q@)matches}:#*\ }" && ret=0
+      compadd -S ' ' - ${${(M)${(Q)matches}:#*\ }% } && ret=0

For the more general case, we'd need to identify characters
with one-level of quoting. Or do a limited number of special cases cover
real-world usage?

Ultimately there's always going to be a mismatch between what needs
quoting in bash and in zsh. Note that in bash no quoting is needed for
git stashes:

bash$ echo stash{1}
stash{1}

So a bash completion for git didn't need to add quotes - hence this
whole discussion. Perhaps we could add an option to allow that. Stuff
like @\{1\}.. is also common in git.

If completion that comes with git is really a lot faster, I think you'd
be better served by finding out why and adding styles to zsh's
completion to allow it to take a faster, more rudimentary approach in
certain cases. It may even already be possible by disabling the right
tags.

Oliver