Re: Bug in completion with curly braces?

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Tue, Nov 24, 2020 at 5:22 PM Oliver Kiddle <opk@xxxxxxx> wrote:

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

It is common to modify IFS in order to add the correct elements to the
COMPREPLY array. As of the multiple levels of quoting I don't know
what you mean. What do you want to add?

> 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

Yes, that should work. Although I think bash would add two spaces if
-o nospace isn't specified.

Recently I tried to do something similar, which left me wondering; why
isn't there a way to specify the suffix already present in the words?

For example Completion/Base/Completer/_expand has code to split into
dir, space, and normal arrays, and add different suffixes to each one
of them.

It would be much easier to somehow say "consider the X ending a suffix".

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

Personally I would like to see "stash@{0}" completed, not
"stash@\{0\}", but anything is better than no completion.

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

Yes, but it's not an easy task.

In the zsh git completion everything creates a huge tree of functions
of functions of functions. Even after I find the actual code that is
doing something, that would only be for one case, then I have to go to
the next one. And that would be only for one command.

In the git bash completion it's just one function, and all the
commands call that function, so it's much easier to understand.

I sent a patch to call git's __git_complete_revlist from inside zsh's
git completion, to showcase one way how this "fast" mode could work.

Cheers.

-- 
Felipe Contreras