Re: __git_recent_commits cannot be called twice Re: [PATCH 2/5] _git: Offer @~$n as completion of recent commits.

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Daniel Shahaf wrote:

> The new output works fine in 'git commit --fixup=<TAB>', but not in 'git
> show <TAB>'.  This is because the latter calls __git_recent_commits via
> two distinct codepaths.  Here's a minimal example:

Calling one function via two codepaths is the basic problem here. We
should avoid doing that rather than trying to hack it to work.

>     25	HEAD    master
>     26	@~0      -- [HEAD]    m (71 seconds ago)
>     27	5d97266  -- [HEAD]    m (71 seconds ago)
> 
> This is only a workaround because grouping @~0 and 5d97266 is desirable,
> since they both refer to the same commit.

Is it really useful to add matches for the abbreviated hashes such as
5d97266? I never type them. Matches for the HEAD form might be more
useful. I'd also consider using the prefix-needed style with the @
form and perhaps even with HEAD. It might be better to cope with the
problem of more than one commit having the same comment by not using
_describe but adding matches manually.

> The underlying problematic behaviour is reproducible without _git:
> 
>      1	$ zsh -f
>      2	% _f() { local -a x=(foo:aaa bar:aaa);  repeat 2 _describe -tt 'desc' x }
>      3	% compdef _f f

_describe removes the 'rows' token from compstate[list]. So given the
following set of matches/descriptions:
  w x -- 0
  y z -- 1
It adds matches in column first order:
  w y x z 0 1

This means the descriptions are all added last so in this case:
  compadd -E2 '-- 0' '-- 1'

With two separate _describe calls, it is like adding the matches in this
order (with setopt nolistrowsfirst):
  w x 0 y z 1
The description matches are very wide due to space padding so it is no
longer able to arrange matches in columns - hence the output you
described.

Perhaps you could change compdescribe to do things in row first order
but it may have other associated problems, particularly when it comes to
the algorithm used to pack matches in suitable column widths.

_describe was written with the assumption that it is fully responsible
for the match group it is adding matches for. It is best to only use it
when that is the case.

I've been thinking that it could be useful to add a helper like
_describe but lacking the feature of grouping matches with a common
description. That's the key feature of _describe. _describe is often
used when it perhaps shouldn't be because it is also a simple and
convenient function when you want descriptions. Any ideas on a name for
such a new helper?

Oliver