Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 4/4] allow recovery from command name typos

From: Tay Ray Chuan <hidden>
Date: 2016-06-15 22:53:45

On Sun, May 6, 2012 at 4:40 PM, Angus Hammond [off-list ref] wrote:
On 6 May 2012 07:55, Tay Ray Chuan [off-list ref] wrote:
quoted
In the case where there is a single suggestion, present the prompt
"[Y/n]", such that "", "y" and "Y" as input leads git to proceed
executing the suggestion, while everything else (possibly "n") leads git
to terminate.
Minor point, as well as ensuring this is configurable behavior, if
terminating is the default, then the prompt should be "[y/N]", so that the
default action is clearly marked. Not capitalising at all would be
reasonable, but making the 'Y' uppercase is actively confusing.
I believe you were referring to the 1/2/.../n case, since for the y/n
case, terminating is not the default.

If so, then yes, the "n" there should be in caps, since terminating is
the default; my bad.
Secondly, if we're at a tty, I suspect this behavior would be totally
unnecessary. Making close suggestions rather than just a complete list is
neat, but if people want to use one of them all they have to do is copy
paste the old command down and modify it, which I suspect would be much
faster than actually considering and responding to a prompt.
I believe that there would be very few options to choose from - in
fact, I was trying very hard to get the number of suggestions to equal
or exceed 5. I guess one would have better luck than I if they studied
the Levenshtein distance algorithm, which I didn't.

In other words - the time to consider is small.

In fact I was hoping this would be faster than copy-paste - typing the
option (1 key) and enter (1 key) makes a total of 2 keys only.

-- 
Cheers,
Ray Chuan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help