Update wezterm support after it added modifyOtherKeys

[rbutoi]

I'm getting some ~32 and non-working M-SPC et al in the buffer since Wezterm started supporting modifyOtherKeys (wez/wezterm#2527) - does this support need updating here?

Originally posted by @rbutoi in #11 (comment)

[CyberShadow]

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?

[rbutoi]

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 #12 who sent that PR unfortunately just before WezTerm's modifyOtherKeys change.

[Lenbok]

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).

[CyberShadow]

I suggest filing a bug against wezterm. modifyOtherKeys probably should not override explicitly configured key bindings.

[Lenbok]

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.

[Lenbok]

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.

[Lenbok]

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.

[rbutoi]

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 emacs-mirror/emacs@b01d024? 2~ is a slightly different output

[Lenbok]

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.