bug#51253: 28.0.60; Meta keys broken when viper is active

[John Cummings]

Stefan Kangas <stefan@marxist.se> wrote:

> John Cummings john@rootabega.net writes:
>
> > Keys like M-x, M-:, etc., are broken in viper
> > vi/insert state since bug
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18182 was fixed in
> > 5d522b430bd5ecfb8f082906cd634883dbb68f3e. This changed viper-ESC-key
> > from <escape> to ESC, which resulted in a direct key binding of (27
> > . 'viper-intercept-ESC-key) while in the viper vi/insert states.
>
> Maybe that commit should just be reverted?

I've looked into this some more, and I think reverting it is the
way that the entirety of the viper ESC-handling stack was designed
to function. At least on terminals. i.e., viper--tty-escape-filter
is meant to translate a solitary ESC into [escape], which
viper-intercept-ESC-key is meant to handle. And on graphical terminals,
we have the prefix vs. direct binding conflict that seems to (in my
limited but growing understanding) completely rule out binding any
commands to ESC.

But if this does get reverted, and it turns out that allowing ESC to
exit vi insert is still important, it doesn't seem like it would be
too difficult to ignore direct ESC command bindings when looking up
meta prefix bindings here:
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/keymap.c?id=f3aa648093a70c8ed15e764863a16fdf7126cdc4#n343
I've been playing with it to help me get more familiar with it; maybe
I'll have a proof of concept one day.