From: Eli Zaretskii <eliz@gnu.org>
To: Len Trigg <lenbok@gmail.com>
Cc: 60077@debbugs.gnu.org
Subject: bug#60077: 29.0.60; Is xterm modifyOtherKeys support broken?
Date: Thu, 15 Dec 2022 11:06:57 +0200 [thread overview]
Message-ID: <83len9kpce.fsf@gnu.org> (raw)
In-Reply-To: <CAOGVwekk7-_2Kt5OyyYmgkPGkagMkcuegVxUs6Qgrd5jwP95Lg@mail.gmail.com> (message from Len Trigg on Thu, 15 Dec 2022 21:38:57 +1300)
> From: Len Trigg <lenbok@gmail.com>
> Date: Thu, 15 Dec 2022 21:38:57 +1300
> Cc: 60077@debbugs.gnu.org
>
> Which terminal file in lisp/term/ was/is Emacs loading at startup when
> you use wezterm?
>
> For both xterm and wezterm I have the $TERM variable set to "xterm-direct", so they both use
> lisp/term/xterm.el (which is consistent with my hack of xterm--init-modify-other-keys affecting the behaviour of
> both). My hypothesis is that under both xterm and wezterm emacs is sending the terminal initialization code
> for turning on modifyOtherKeys, but the older version of wezterm just ignored it (and M-SPC worked). But now
> they have added modifyOtherKeys support, it is behaving like xterm (i.e. broken) by sending M-SPC with an
> encoding that emacs doesn't recognize. Do you think it's just a matter of the dolist on line 466 of xterm.el
> needing additional entries (I don't see one there for M-SPC)?
I don't really know. But one solution is to disable modifyOtherKeys
in your init file. Or maybe you could dig deeper into what xterm.el
does with modifyOtherKeys support and tell why M-SPC fails.
prev parent reply other threads:[~2022-12-15 9:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 21:48 bug#60077: 29.0.60; Is xterm modifyOtherKeys support broken? Len Trigg
2022-12-15 6:41 ` Eli Zaretskii
2022-12-15 8:38 ` Len Trigg
2022-12-15 8:57 ` Len Trigg
2022-12-15 9:10 ` Eli Zaretskii
2022-12-15 19:48 ` Len Trigg
2022-12-16 6:52 ` Eli Zaretskii
2022-12-16 7:40 ` Eli Zaretskii
2022-12-16 16:04 ` Eli Zaretskii
2022-12-15 9:06 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83len9kpce.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=60077@debbugs.gnu.org \
--cc=lenbok@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).