Why can't I set \C-e in inputrc to be end-of-line for vi-command keymap?

Question

I have this in my .inputrc, but Control-e doesn't move to end of line in command mode. All other bindings work.

$if mode=vi
    set show-mode-in-prompt on

    set keymap vi-insert
    "\C-e": end-of-line
    "\C-a": beginning-of-line

    set keymap vi-command
    "\C-e": end-of-line
    "\C-a": beginning-of-line
$endif

I can see it's taking:

$ bind -p | grep 'end-of-line'
"\C-e": end-of-line
"\eOF": end-of-line
"\e[F": end-of-line

And I can see nothing else is bound to \\Ce:

$ bind -p | grep 'C-e'
"\C-e": end-of-line
"\C-x\C-e": shell-expand-line

If I set it to \\Cl, it works. So, what's special about \\Ce in readline's vi mode that I'm not able to override?

Only other clue is \\Ce causes a terminal beep.

Nothing else is in my .inputrc

Answer 1

I just tried and it also does not work for me. But the bind command works fine:

bind -m vi-command ' "\C-e": end-of-line '

Seems like there's something weird in readline loading .inputrc . So as a workaround you can put the bind command in your bashrc files.

Answer 2

According to Chet Ramey via the bug-bash@gnu.org mailing list,

This has been there forever. The default readline vi command-mode keymap has ^E bound to switch to emacs editing mode. Since bash uses `set -o emacs' for that, the bash readline initialization code unbinds the key sequence. It needs to make sure that the function it's bound to is still rl_emacs_editing_mode.

He provides a patch, which is probably beyond the scope of a SO answer here, so I'll just link to it: http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00217.html

@pynex's workaround works fine.