Re: _git: Improve handling of aliases

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Miroslav Koškár wrote on Sat, 27 Jun 2020 11:04 +0200:
> Hi Daniel,
> 
> bellow to things not addressed in my recent patchset.
> 
> On Jun 26, Daniel Shahaf wrote:
> > Sure.  Alternatively, we could continue to retrieve all aliases but
> > cache that list between calls (see _store_cache; there are examples in
> > _subversion).  
> 
> I see, good to know. It seems fast enough to me as is so *shrug*.
> 
> > Well, yes and no.  The arguments to shell aliases seem to be handled
> > similarly to arguments to «eval»: joined by spaces and then passed to
> > system(3).  That means it's valid to pass the entire string in a single
> > shell word, or to translate any of the spaces in the desired result
> > string into word breaks at the shell input level, just like «eval hello
> > world» and «eval 'hello world'» are equivalent.
> >
> > So, how about completing this the same way «eval -- <TAB>» is completed?
> > Currently ${_comps[eval]} is _precommand, which just calls _normal, but
> > that's incomplete¹.  If we write the code to do something along the
> > lines of «words=(eval -- …); CURRENT=…; _normal», it'll automatically
> > grow support for completing both variants once such support is added to
> > «eval»'s completion.²
> >
> > ¹ For example, «eval 'git -c' <TAB>» completes files rather than
> >   configuration options, because it takes 'git -c' rather than just 'git'
> >   to be the command word.
> >
> > ² That'd be something along the lines of «words=( ${=:-"${words}"} )»,
> >   I guess?  Plus adjusting $CURRENT, etc..  
> 
> Right, I understand your points generally. I see the similarity to eval,
> even though there is an important distinction I think:
> 
>     (git alias) test = !echo hello
>     $ git test \; world
>     hello ; world
> 
> So git executes aliases more akin to:
> 
>     sh -c 'echo hello "$@"' arg0 \; world
> 
> As for doing 'words=(eval ...); _normal', it doesn't work for complex
> commands e.g., eval cd dir '&&' ls -<TAB>.

Okay; that's a bug in «eval»'s completion.

> I understand you would like to have that work in future and I agree what
> would be cool and would certainly help here. With my limited knowledge
> of zsh internals and complexity of completion I'll leave this to others
> :).

The easiest way to get started would be to edit _precommand and add
special-case code for when [[ $service = eval ]].  Before committing
we might break out the code to a separate file, but don't worry about
that at this stage; the roadblock is the "handle spaces and command
separators" logic, not the spinning off a new file.  I imagine the
algorithm would be something like:

1. Join all the words with spaces.
2. Pass through ${(z)} [or ${(Z)} for comments support].
3. Trim all words that are before (after) the command separator before
(after) the cursor.
4. I'm not 100% sure about the next step.  Set IPREFIX and ISUFFIX
correctly and then call _cmdstring?

> While proposed split on simple command separators might seem crude
> it actually works quite fine.

Indeed.

> > As above, I'd prefer to delegate to «eval»'s completion.  Alternatively,
> > my previous point about supporting comments stands.  
> 
> Ahhh, so that's (Z+C+) instead of (z), forgot about that.
> Well it's not like a common case to use comments there, mind you it's
> a bit weird to even use them in gitconfig, managed to make an example:
> 
>     test = !echo hello \n \
>         "#" let this be a commented line \n \
>         echo world
> 

Ah, nice, thanks for figuring that out!  Given it's so awkward, and not
supported by the incumbent code, I'd say it's not a priority to support.

> Ok, I'll wait for your comments on the patchset I've sent before and
> this too and then either incorporate (Z+C+) with other changes or sent
> it separately.

Sure.

I've applied the first two patches of the set (thanks!).  Patch 3/4
looks larger; I'm not sure I'll be able to review it tonight, and
unfortunately I have a busy few days ahead of me.  (-workers@, if
anyone wants to jump in, feel free.)

Cheers,

Daniel