Re: [PATCH v4 4/4] completion: simplify __gitcomp*

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v4 4/4] completion: simplify __gitcomp*

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:57

SZEDER Gábor [off-list ref] writes:
And it does make a difference, it breaks the completion of a single
word in multiple steps, e.g. git log --pretty=<TAB> master..<TAB>.  In
such cases we pass "${cur##--pretty=}" and "${cur_#*..}" as third
argument to __gitcomp() and __gitcomp_nl(), which can be empty strings
when the user hits TAB right after the '=' and '..'.
After saying "this rewrite is wrong", I was actually wondering if I should
have said "this rewrite is not faithful to the original".  Based on your
analysis, the difference does break the callers, so the rewrite is indeed
wrong.

Thanks for following up.

Re: [PATCH v4 4/4] completion: simplify __gitcomp*

From: Felipe Contreras <hidden>
Date: 2016-06-15 22:52:57

2012/2/5 Junio C Hamano [off-list ref]:
SZEDER Gábor [off-list ref] writes:
quoted
And it does make a difference, it breaks the completion of a single
word in multiple steps, e.g. git log --pretty=<TAB> master..<TAB>.  In
such cases we pass "${cur##--pretty=}" and "${cur_#*..}" as third
argument to __gitcomp() and __gitcomp_nl(), which can be empty strings
when the user hits TAB right after the '=' and '..'.
After saying "this rewrite is wrong", I was actually wondering if I should
have said "this rewrite is not faithful to the original".  Based on your
analysis, the difference does break the callers, so the rewrite is indeed
wrong.
That's why we need tests for the completion stuff as well. I was
thinking on doing that, but if I have to write a peer-reviewed essay
with an introduction for the people that are not familiar with the
code in each of the patches, I'd rather not.

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help