Open rbutoi opened 1 year ago
If wezterm is not obeying the settings in its configuration file, then that would be a bug in wezterm.
Have you tried turning off the modifyOtherKeys
feature?
Have you tried turning off the modifyOtherKeys feature?
AFAICT, it's not an option in a config file, it's just enabled. I'll get in touch with the author of https://github.com/CyberShadow/term-keys/pull/12 who sent that PR unfortunately just before WezTerm's modifyOtherKeys
change.
I've updated my wezterm and are also now getting this. I'm not sure exactly the best way to update term-keys to make this work The Right Way, but as a quick workaround I've told emacs to not send the modifyOtherKeys
initialization to the terminal, via:
;; Dirty hack to not use xterm modifyOtherKeys feature
(defun my-disable-xterm--init-modify-other-keys (orig-fun &rest args))
(advice-add #'xterm--init-modify-other-keys :around
#'my-disable-xterm--init-modify-other-keys)
Alternatively it should be possible to set xterm-extra-capabilities
to a list that contains the capabilities that are supported but does not include modifyOtherKeys
.
That certainly fixes M-SPC
(I don't know what other keys were also affected).
I suggest filing a bug against wezterm. modifyOtherKeys
probably should not override explicitly configured key bindings.
I'm not sure if it's entirely that simple.
The set of keybindings generated by term-keys/wezterm-conf
doesn't even output a binding for M-SPC
(for whatever reason). I had assumed that it would need to be extended to output a correct binding, but really if emacs supposedly supports modifyOtherKeys
, that suggests that M-SPC
should work out of the box in vanilla emacs + wezterm (i.e. no term-keys
required for that binding). So maybe it is a wezterm bug after all.
Update: when I use xterm -e emacs -nw -Q
, M-SPC
inserts ~32
as well. If I put my dirty hack into a $HOME/test-dir/init.el
then xterm -e emacs -nw --init-dir=$HOME/test-dir
has M-SPC
binding working as expected. So wezterm and xterm are behaving the same way, suggesting it's a bug in emacs' modifyOtherKeys
handling? I really don't know enough about how this stuff works.
Indeed it seemed to be an emacs bug (or rather, incompleteness). I reported it at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60077 which has been fixed (at least for M-SPC
in emacs-29). @rbutoi If there are other keys that have the same issue, they could be added to the emacs modifyOtherKeys
support in the same manner.
Thank you! And yes, shift+space is another one I can immediately notice:
<key> <output>
M-SPC ;32~
S-SPC 2~
S-M-SPC ;32~
There could be others though. So to fix this, I could add something like https://github.com/emacs-mirror/emacs/commit/b01d0246d71a7a3fd92b2864a3c0c0bc9367ee0b? 2~
is a slightly different output
I got the info for that patch by looking at the table in "other modified-key escapes" at https://invisible-island.net/xterm/modified-keys-us-pc105.html where the first two numbers of the emacs binding element in that big list in xterm.el
are those between the semicolons in the escape code shown in the "mode 2" column, so for S-SPC
you would want something like (2 32 [S-SPC])
and for S-M-SPC
you would want (4 32 [S-M-SPC])
.
If you use emacs server mode, then in one client you can make the changes to your xterm.el, re-evaluate the xterm-function-map
declaration, and then start a new emacsclient instance in the terminal to test the new settings. Once you've got a set of working new bindings, I guess send them to the emacs guys for inclusion.
That's assuming you want to make the changes in xterm.el
for upstreaming back to emacs. I guess the alternative is to directly add bindings to the xterm-function-map
from your init.el
but I haven't tried that.
I'm getting some
~32
and non-working M-SPC et al in the buffer since Wezterm started supportingmodifyOtherKeys
(https://github.com/wez/wezterm/issues/2527) - does this support need updating here?Originally posted by @rbutoi in https://github.com/CyberShadow/term-keys/issues/11#issuecomment-1296494936