sh: move histedit() call outside of test for bind -

[emaste]

Summary

It appears that bind resets vi/emacs mode, so call histedit() after every bind call to make sure the state remains consistent.

This might be a bigger hammer than necessary, or it might be that this should be addressed in libedit itself.

PR: 280889

[pstef]

I believe the problem was introduced in 5fe973734866 or ef0d94a3d34c where ^[[A is introduced. I think libedit doesn't have the code to parse that properly. Fortunately it can be replaced with \e.

https://reviews.freebsd.org/P645 is a diff that teaches libedit how to parse it, by the way.

[emaste]

In D46321#1056451, @pstef wrote:

https://reviews.freebsd.org/P645 is a diff that teaches libedit how to parse it, by the way.

That change LGTM if you want to commit it.

[pstef]

In D46321#1056465, @emaste wrote:

In D46321#1056451, @pstef wrote:

https://reviews.freebsd.org/P645 is a diff that teaches libedit how to parse it, by the way.

That change LGTM if you want to commit it.

Unfortunately I was wrong and it actually doesn't change anything except perhaps it improves code clarity.

To quote my email to Christos:

The actual problem is the interaction between vi mode and binding the up
arrow key to anything I tested, including the ed-search-prev-history
that some users demanded from us. Tests are easier for me when I try
ed-prev-char.

cd /tmp ; set -o vi ; bind > before ; bind ^[[A ed-prev-char
bind > after ; diff -Bwu before after

-"^[" -> vi-command-mode
+"^[" -> ed-sequence-lead-in

-"^[[A" -> ed-prev-history
+"^[[A" -> ed-prev-char

Then the vi bindings are gone, for example esc-K.

If I replace ^[[A with -k up, the former change is no longer there and
the latter is listed as a key arrow bind. But the behavior is not the
one I expected: the up key brings previous commands.

I'll try to find some time to think about if this is fixable and how.
But it seems it should be in principle since vi handles the arrow keys
properly in command mode.