Re: [Illustration PATCH] add -i: accept single-keypress input

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2009, 05:10 UTC
Message-ID: <7vljsm9492.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200902031035.04978.trast@student.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 11 quoted lines

> Junio C Hamano wrote:
>
>> Hmm, you could trigger the action immediately after seeing _enough_ number
>> of characters to disambiguate instead of stop-and-prompt, I guess?  That
>> way, you would get a single-key merely as a degenerate case when the
>> choices are all distinct.
>
> I don't think that's very nice.  On the one hand, you'd really want to
> allow the user to delete some of the input again if he decides to do
> something else instead, and we'd either need readline or need to
> reinvent it for that....

But doesn't the original "single-keypress" theme shares that problem anyway? It trades the ability to "delete some of the it again if he decides to" away, in exchange for something else (probably "quicker input" or "perceived ease of use").

Show 5 quoted lines

> ....  On the other hand, some possible choices might
> be a valid prefix of some _other_ choices, at which point you need a
> terminator (such as the <enter>) anyway.  I expect this to be fairly
> common since many of the list_and_choose() prompts are numbered, so
> that 1 and 10 run into this problem.

I think that is independent, is an easy to fix (e.g. 1..9 A B C...Z), and is a chicken-and-egg issue. If the input mechanism had "enough leading letters to disambiguate" semantics from the beginning, I am reasonably sure that list_and_choose() would have implemented its choice as not small integers but distinct letters.