Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Ramkumar Ramachandra wrote:
> Frank Terbeck wrote:
[...]
>> follows git's development too closely that's a battle you cannot win.
[...]
> mailing list.  Like I said before: I'm not taking sides, so there's no
> "battle": it's a simple task of picking one completer, and merging the
> other's strengths into it.

That's not how I meant "battle". I meant that one person cannot keep up
with the rate at which git moves. I didn't mean it in the bash vs zsh
completion sense. If the bash completion works well, that's great.

[...]
>> completion). Long story short, Felipe's rather hostile tone got him a
>> pretty short-spoken final reply from Nikolai, which he now shows off to
>> anyone who does or doesn't ask.
>
> Got it.  However, why are we talking about him?  We're not interested
> in changing Felipe's behavior (even if we did have some magical way to
> do that).  Let us focus on which completer to work on by looking at
> the two completers.

I merely provided some context, but you've obviously got a point there. ;)

>> This whole _git business is rather off-putting and I'd like to avoid
>> putting any more time and energy into any "politics" that are involved
>> on either side. This is no fun. I don't want to get steamed up about
>> things like this.
>
> Why are you getting steamed up?  What politics are you talking about?
> Someone on the internet has a rather strong opinion on zsh's
> completer, and he tells it to whoever asks him.  That's it.

Discussing with reasonably mannered people is no problem at all. People
on the other hand, who are abusive and insulting for no particular
reason other than the effect it has on the people on the other side of
the "discussion" can be infuriating - which is obviously what they are
aiming for, but what can you do. ;)

I'd really like to follow your suggestion and drop this matter now.

>> This thing with speed is this: Yes, _git is slower than the bash
>> completion. But - at least when I last looked - _git will provide much
>> more useful suggestions depending on the context of the cursor position.
>> And I - personally - am happy to wait for, say, a second if that means I
>> can save several seconds selecting the right choice. However, some
>> completions are too slow on really large repositories. That would be a
>> useful area to improve - maybe make the slow smartness optional? I don't
>> know.
>
> The question is: which way to start work from?
[...]

I don't know. It seems that the two completers have different
philosophies in the ways they work, so merging them seems like a
long-running and tedious job.

Like I said before, having a source that describes possible completions
would be a step in the right direction. Also, non-bourne-like shells
like tcsh and fish could benefit from that.


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925