unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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 12:49:58 +0300	[thread overview]
Message-ID: <83tu8bemk9.fsf@gnu.org> (raw)
In-Reply-To: <87k097hixh.fsf@yahoo.com> (message from Po Lu on Thu, 23 Jun 2022 16:40:10 +0800)

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  56117@debbugs.gnu.org,  stefan@marxist.se,
>   qsx@chaotikum.eu
> Date: Thu, 23 Jun 2022 16:40:10 +0800
> 
> Eli Zaretskii <eliz@gnu.org> 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.





  reply	other threads:[~2022-06-23  9:49 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
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 [this message]
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=83tu8bemk9.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).