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

[Alexey Dokuchaev]

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.

./danfe