Hi Martin,
Martin Natano wrote on Mon, Aug 08, 2016 at 08:21:50AM +0200:
> On Mon, Aug 08, 2016 at 03:33:23AM +0200, Ingo Schwarze wrote:
>> redirecting from misc@ to tech@ because i'm appending a patch
>> at the very end, lightly tested.
>>
>> This has indeed been annoying me for years, but it never occurred
>> to me that i might be able to figure out what's going on.
>> Thanks for providing your analysis, i think it's spot on.
>>
>> So the solution is to not swallow up that escape character, right?
> Thats not always correct. With your patch ksh now eats the next key
> you type when you exit the search prompt with the escape key.
According to the documentation, typing the escape key alone is not
a supported method of exiting the search prompt. The ksh(1) manual
says:
search-history: ^R
Enter incremental search mode. [...]
The abort key will leave search mode.
Above, the term "abort key" is defined as follows:
abort: ^C, ^G
Useful as a response to a request for a search-history
pattern in order to abort the search.
And indeed, Ctrl-C and Ctrl-G work as expected to abort search-history.
The search-history description does not say anything that the escape
key could be used to leave search mode, nor do i see such a statement
anywhere else; instead, the search-history description goes on as
follows:
Other commands will be executed after leaving search mode.
As i read that, commands like
backward-word: [n] ^[b
beginning-of-history: ^[<
capitalize-word: [n] ^[C, ^[c
comment: ^[#
complete: ^[^[
complete-file: ^[^X
complete-list: ^I, ^[=
delete-word-backward: [n] ERASE, ^[^?, ^[^H, ^[h
delete-word-forward: [n] ^[d
downcase-word: [n] ^[L, ^[l
end-of-history: ^[>
expand-file: ^[*
forward-word: [n] ^[
goto-history: [n] ^[g
list: ^[?
prev-hist-word: [n] ^[., ^[_
search-character-backward: [n] ^[^]
set-mark-command: ^[<space>
upcase-word: [n] ^[U, ^[u
yank-pop: ^[y
qualify as "other commands", and i don't see why it should matter
whether i type both bytes almost instantaneously or whether there
is a noticable delay between the two.
For that reason, i prefer my version of the patch to yours, and in
addition to being arguably better, it is certainly much simpler.
That said, i don't strongly object to yours, i also consider it
better than the current situation.
> The only way to know whether the esacpe is part of a longer
> sequence or was typed by the user
I don't understand at all why that should matter.
Yours,
Ingo
