Subject: bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","

From: Eli Zaretskii <[email-masked]>
Date: Thu, 23 Jun 2022 12:49:58 +0300

> From: Po Lu <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],
>   [email-masked]
> Date: Thu, 23 Jun 2022 16:40:10 +0800
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > 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?
> 
> Basically, GTK input methods (which are maintained outside GTK) tend to
> "swallow" the difference between keypresses like "C-S-u" and "C-u",
> along with the difference between "kp-separator" and the separator
> itself.
> 
> The reason is that doing so is slightly more convenient for the input
> method developers, and most GTK programs, unlike Emacs, have no need to
> tell those keypresses apart.

And there's absolutely no way for Emacs to get at the original keys?
Or for users to configure their systems so as to work around this
"swallowing"?  I have hard time believing that no one has discovered
any workarounds for this misfeature.  Emacs may be rare in its needs
of accessing keys, but it cannot be the only application that does
that.  The NumLock key is there for a reason, and applications do use
it.

> So in practice, Emacs users either have the choice of disabling the use
> of system input methods, or putting up with those issues.

Can those system input methods be easily toggled, which would allow to
disable them temporarily, just for the period of time the kp-* keys
are needed?

> They are already documented in PROBLEMS, but somehow we still get a
> continuous stream of people reporting them as bugs in Emacs.

Because it's an annoying problem, I'm guessing, and the solution has
downsides that users perhaps consider annoying as well.  PROBLEMS is
only a satisfactory solution when a problem is rare or the solution
doesn't rob one of too much of useful functionality.