GNU bug report logs - #51253
28.0.60; Meta keys broken when viper is active

Previous Next

Full log

Message #11 received at 51253 <at> debbugs.gnu.org (full text, mbox):

From: John Cummings <john <at> rootabega.net>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51253 <at> debbugs.gnu.org
Subject: bug#51253: 28.0.60; Meta keys broken when viper is active
Date: Tue, 19 Oct 2021 23:32:09 +0000

Stefan Kangas <stefan <at> marxist.se> wrote:

> John Cummings john <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.