svn commit: r325092 - head/usr.bin/fortune/datfiles

[Dan Mack]

Alexey Dokuchaev <danfe at FreeBSD.org> writes:

> On Mon, Oct 30, 2017 at 04:35:04PM -0500, Dan Mack wrote:
>> Definately different. Better? Maybe for some.  I most always search
>> command history by prefix and then just using multiple ESC-p invocations
>> to find the one command to edit/re-execute.  Less frequently I want to
>> search the whole text of history for the whole command line sequence
>> like bash Ctrl-R accomplishes.
>
> Agreed, search-by-prefix needed a lot more often than ^R one (search
> anywhere).  That's why it makes sense to bind it to the arrows.
>
>> >>> "\ep": history-search-backward
>> >>> "\en": history-search-forward
>> 
>> > Interesting that you mapped these to cursor-up/cursor-down.
>> >
>> > That may cause unexpected results.
>> 
>> > For example, typing something and then pressing up-arrow will cause
>> > the shell to give you the previous command that started with that
>> > rather than the previous command in-general.
>
> That's exactly what I want, to type vi<up> and instantly get to the
> editing command (skipping all cd's and ls's I might've done in between).
>
>> It's ESC-p/ESC-n, not just plain up-arrow/down-arrow.  Up arrow still
>> does up without any search.  At least with my config using \ep as shown.
>> My up arrows work for me as expected - they just iterate forward and
>> backward through shell history.
>
> I find this separation useless and actually mitigating the good.  When
> I want to scroll the history without any search I'd simply won't type
> anything.  Binding prefix-search to ESC-p/ESC-n, not up-arrow/down-arrow
> is beyond me.  Empty command line gives you plain iteratation, typing
> anything limit iteratation over commands starting with typed prefix.

Maybe this disconnect is related to the fact that I never use the
arrow keys. I used ctrl-n/p to cycle shell history down/up and put an
esc in front if I am searching using history-search-backward/forward.

Dan