From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: larsi@gnus.org, stefan@marxist.se, 56117@debbugs.gnu.org,
qsx@chaotikum.eu
Subject: bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
Date: Thu, 23 Jun 2022 11:28:39 +0300 [thread overview]
Message-ID: <83wnd7eqbs.fsf@gnu.org> (raw)
In-Reply-To: <87sfnvhk0m.fsf@yahoo.com> (bug-gnu-emacs@gnu.org)
> Cc: 56117@debbugs.gnu.org, stefan@marxist.se, qsx@chaotikum.eu
> Date: Thu, 23 Jun 2022 16:16:41 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > And as both Eli and I have said, we think those changes you've made to
> > pgtk here should be reverted so that these keys work as before.
>
> This isn't the super-key related bug, and in fact they shouldn't have
> been merged. No amount of changes on our side can work around input
> methods swallowing the shift modifier in "C-S-u" and the "kp-" in
> "kp-separator".
Maybe we are talking about an issue that is not understood well enough
by some participants (e.g., myself). Can you please describe in more
detail what causes this particular issue?
> > Even though it's "wrong". Maintaining a user-facing program like
> > Emacs is 70% dealing with bugs and misfeatures in other systems we're
> > interfacing with.
>
> I'm trying to figure out how all of that fits together in Wayland to
> hopefully fix it in GTK upstream. Hard-coding real modifier values is
> very fundamentally wrong under both X and GTK, and leads to extremely
> hard-to-diagnose problems down-the-road.
Instead of hard-coding them, we could have them in some Lisp data
structure, where both changing them and eliminating them altogether
will be much easier. Just an idea.
next prev parent reply other threads:[~2022-06-23 8:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 23:02 bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/"," Thomas Schneider
2022-06-21 2:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-22 20:44 ` Stefan Kangas
2022-06-23 0:44 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-23 7:51 ` Lars Ingebrigtsen
2022-06-23 8:16 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-23 8:28 ` Eli Zaretskii [this message]
2022-06-23 8:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-23 9:49 ` Eli Zaretskii
2022-06-23 10:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-23 10:19 ` Eli Zaretskii
2022-06-23 11:37 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-23 13:00 ` Eli Zaretskii
2022-06-24 5:58 ` Kévin Le Gouguec
2022-06-24 16:43 ` Kévin Le Gouguec
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=83wnd7eqbs.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=56117@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=luangruo@yahoo.com \
--cc=qsx@chaotikum.eu \
--cc=stefan@marxist.se \
/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).