Re: [Bug-readline] Ctrl-W (erase word) in vi editing-mode has wrong behavior

[John Florian]

On Wed, 2017-08-02 at 09:04 -0400, Chet Ramey wrote:

> On 8/1/17 3:53 PM, John Florian wrote:
> > I just reported the following on
> > https://bugzilla.redhat.com/show_bug.cgi?id=1477328:
> >
> > """
> >
> > Description of problem:
> > Ctrl-w now stops at word-breaking characters rather than spaces as it's done for a very long time.
>
>
> This has come up a few times previously, originally as a result of
>
> http://lists.gnu.org/archive/html/bug-readline/2016-02/msg00001.html
>
> The most recent report is:
>
> http://lists.gnu.org/archive/html/help-bash/2016-11/msg00003.html
>
> The explanation and a way to get the old behavior are here:
>
> http://lists.gnu.org/archive/html/bug-readline/2016-02/msg00002.html
>
> and here, respectively:
>
> http://lists.gnu.org/archive/html/help-bash/2016-11/msg00004.html
>
> Chet

Chet, Thank you so much! Readline is like knees, you totally take it/them for granted until you have troubles with it/them.

I couldn't seem to get the ^w bound to plain old unix-word-rubout and always got vi-unix-word-rubout instead until reading that last link above where the secret was revealed:

set bind-tty-special-chars off

It's funny, as a die-hard vim user who knows nothing of emacs beyond how to spell it and that one must be good at pressing multiple key modifiers concurrently, I would have never guessed that I much prefer the emacs way of erasing the prior word, at least at bash prompt. It's probably nothing more than being accustomed to one way simply because that was once the default. In fact, many of my readline, bash and vim configuration exists to restore prior default behavior. Philosophically, I think we developers are better at preserving backwards-compatibility in APIs than UIs. That's not a slight on this behavioral change, it does seem the right thing to have done.

On a sort of related note, have you seen the efforts to integrate neovim into readline for truer vim behavior?