all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
@ 2022-06-20 23:02 Thomas Schneider
  2022-06-21  2:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas Schneider @ 2022-06-20 23:02 UTC (permalink / raw)
  To: 56117


Dear maintainers,

With “classic” X11 support in Emacs and GTK (probably the others, too),
pressing the keypad separator ("," on, e.g., a german keyboard layout,
"." on most others), gave emacs the key <kp-separator>.  With pgtk, this
is no longer the case.

This is a feature regression, because it no longer allows, for example,
remapping <kp-separator> to "." for `calc-digit-map`, so I can’t enter
decimal numbers using only the keypad.  As a workaround, I currently
have (define-key calc-digit-map (kbd ",") "."), but if I wanted to use
the vector feature of calc, I’d no longer have the comma.

Steps to reproduce:
> fictive-window-manager-control set-keyboard-map de
> # maybe some locale stuff, who knows
> ./configure --with-pgtk && make
> src/emacs -Q
> C-h k <kp-separator>

Expected output:
> , (translated from <kp-separator>) runs the command […]

Actual output:
> , runs the command […]

I traced this a bit.  In pgtkterm.c:key_press_event(),
pgtkim.c:pgtk_im_filter_keypress() is called, which essentially defers
to gtk_im_context_filter_keypress() from GTK.  From its
documentation[0]:

> Allow an input method to internally handle key press and release
> events.  If this function returns `TRUE`, then no further processing
> should be done for this key event.

Well, okay.  Unfortunately, I barely know enough GTK to get the gist of
what is happening here, by far not enough to fix this issue.

[0]: https://docs.gtk.org/gtk3/method.IMContext.filter_keypress.html


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.16.0)
 of 2022-06-11 built on localhost
Repository revision: 98365c7b1e1e1d3d5f7185f2d4a2baa1c65b4540
Repository branch: master
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-29.0.9999
 --htmldir=/usr/share/doc/emacs-29.0.9999/html --libdir=/usr/lib64
 --program-suffix=-emacs-29-vcs --includedir=/usr/include/emacs-29-vcs
 --infodir=/usr/share/info/emacs-29-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --with-dbus --with-modules --with-gameuser=:gamestat --with-libgmp
 --with-gpm --with-native-compilation --with-json --with-kerberos
 --with-kerberos5 --with-lcms2 --with-xml2 --without-mailutils
 --without-selinux --without-sqlite3 --with-gnutls --with-libsystemd
 --with-threads --without-wide-int --with-zlib --with-sound=alsa
 --with-pgtk --without-x --without-ns --with-toolkit-scroll-bars
 --without-gconf --with-gsettings --with-harfbuzz --with-libotf
 --with-m17n-flt --with-xwidgets --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-webp --with-imagemagick
 --with-dumping=pdumper 'CFLAGS=-O2 -pipe -march=native -g'
 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS
TIFF TOOLKIT_SCROLL_BARS WEBP XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LC_MESSAGES: en_GB.UTF-8
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  bug-reference-prog-mode: t
  pdf-occur-global-minor-mode: t
  rainbow-delimiters-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-autoresize-mode: t
  helm--remap-mouse-mode: t
  async-bytecomp-package-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  auto-revert-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-idle-scheduler-mode: t
  semantic-mode: t
  TeX-PDF-mode: t
  display-battery-mode: t
  display-time-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
/home/qsx/.emacs.d/elpa/dpkg-dev-el-20190824.2314/debian-autoloads hides /home/qsx/.emacs.d/elpa/debian-el-20211006.1939/debian-autoloads
/usr/share/emacs/site-lisp/cmake-mode hides /usr/share/emacs/site-lisp/cmake/cmake-mode
/usr/share/emacs/site-lisp/desktop-entry-mode hides /usr/share/emacs/site-lisp/desktop-file-utils/desktop-entry-mode
/home/qsx/.emacs.d/elpa/transient-20220527.2213/transient hides /usr/share/emacs/29.0.50/lisp/transient
/usr/share/emacs/site-lisp/mercury/gud hides /usr/share/emacs/29.0.50/lisp/progmodes/gud
/usr/share/emacs/site-lisp/mercurial/mercurial hides /home/qsx/.emacs.d/elisp/mercurial

Features:
(shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file url-dired svg
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win
emacsbug semantic/tag-write semantic/bovine/make
semantic/decorate/include semantic/bovine/make-by make-mode image-file
image-converter helm-config semantic/edit novice help-fns radix-tree
ffap cus-start mule-util ace-window avy helm-x-files helm-for-files
helm-bookmark helm-adaptive helm-external helm-net gud winner
tramp-archive tramp-gvfs tramp-cache zeroconf helm-command helm-elisp
helm-eval edebug debug backtrace helm-info misearch multi-isearch
semantic/decorate/mode ebuild-mode skeleton quilt semantic/tag-file
vc-git vc vc-dispatcher bug-reference xcscope gnus-alias gnus nnheader
range calc calc-loaddefs rect calc-macs ledger-mode ledger-check
ledger-texi ledger-test ledger-sort ledger-report ledger-reconcile
ledger-occur ledger-fonts ledger-fontify ledger-state ledger-complete
ledger-schedule ledger-init ledger-xact ledger-post ledger-exec
ledger-navigate eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg
esh-module esh-groups esh-util ledger-context ledger-commodities org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-sqlite ob-sql ob ob-tangle org-src ob-ref ob-lob ob-table
ob-exp ob-comint ob-emacs-lisp ob-core ob-eval org-table oc-basic ol
org-keys oc org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs ledger-regex haskell-mode haskell-cabal haskell-utils
haskell-font-lock haskell-indentation haskell-string
haskell-sort-imports haskell-lexeme haskell-align-imports
haskell-complete-module haskell-ghc-support noutline outline etags
fileloop generator xref dabbrev haskell-customize adoc-mode tempo
markup-faces json-mode json-snatcher js llvm-mode toml-mode conf-mode
align pdf-occur ibuf-ext ibuffer ibuffer-loaddefs tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent pdf-isearch
let-alist pdf-misc pdf-tools pdf-view magit-bookmark bookmark jka-compr
pdf-cache pdf-info tq pdf-util pdf-macs dockerfile-mode sh-script
executable yaml-mode poly-ansible polymode poly-lock polymode-base
polymode-weave polymode-export polymode-compat polymode-methods
polymode-core polymode-classes poly-ansible-jinja2-filters jinja2-mode
sgml-mode facemenu dom ansible-doc ansible f f-shortdoc shortdoc
rainbow-delimiters stripe-buffer advice meson-mode smie apache-mode
form-feed helm-rg helm-mode helm-misc helm-files image-dired xdg
image-mode exif tramp tramp-loaddefs trampver tramp-integration cus-edit
cus-load files-x tramp-compat parse-time ls-lisp helm-buffers helm-occur
helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help
helm-types helm helm-global-bindings helm-easymenu helm-core
async-bytecomp helm-source helm-multi-match helm-lib async
magit-submodule magit-obsolete magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func imenu
magit-diff smerge-mode diff diff-mode git-commit log-edit message
sendmail yank-media rmc puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process with-editor shell pcomplete magit-mode transient comp
comp-cstr magit-git magit-base magit-section compat-27 compat-26 compat
srefactor srefactor-ui recentf tree-widget cl srecode/semantic
semantic/senator semantic/decorate pulse color srecode/insert
srecode/filters srecode/args ede/speedbar ede/files ede ede/detect
ede/base ede/auto ede/source eieio-speedbar speedbar dframe eieio-custom
wid-edit srecode/find srecode/map srecode/ctxt srecode/compile
srecode/dictionary srecode/fields srecode/table srecode semantic/doc
semantic/db-file data-debug cedet-files semantic/bovine/c hideif
semantic/bovine/c-by semantic/lex-spp semantic/bovine/gcc semantic/dep
semantic/bovine semantic/analyze/refs semantic/db-find semantic/db-ref
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs semantic/db-mode semantic/idle semantic/analyze
semantic/sort semantic/scope semantic/analyze/fcn semantic/db eieio-base
semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt
semantic/util-modes semantic/util semantic pp semantic/tag semantic/lex
semantic/fw mode-local find-func cedet company-shell dash
company-ansible company-ansible-keywords company-reftex s reftex-cite
reftex reftex-loaddefs reftex-vars company-bibtex parsebib bibtex
iso8601 time-date company-auctex yasnippet latex edmacro kmacro
latex-flymake flymake-proc flymake project compile text-property-search
comint ansi-color ring warnings thingatpt tex-ispell tex-style tex crm
texmathp company-math math-symbol-lists company pcase cl-extra help-mode
format-spec battery dbus xml time deeper-blue-theme server use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core finder-inf
site-gentoo adoc-mode-autoloads tex-site dpkg-dev-el debian-el
company-autoloads haskell-mode-autoloads ledger-mode-autoloads
lsp-ui-autoloads lsp-mode-autoloads magit-autoloads git-commit-autoloads
markdown-mode-autoloads magit-section-autoloads parsebib-autoloads
pdf-tools-autoloads f-autoloads dash-autoloads rx transient-autoloads
helm-autoloads helm-core-autoloads with-editor-autoloads info
compat-autoloads package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map url-vars seq
gv subr-x byte-opt bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 1254619 103414)
 (symbols 48 60678 0)
 (strings 32 320403 12785)
 (string-bytes 1 8827985)
 (vectors 16 124981)
 (vector-slots 8 2072939 72589)
 (floats 8 626 456)
 (intervals 56 14002 101)
 (buffers 992 35))





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-21  2:00 UTC (permalink / raw)
  To: Thomas Schneider; +Cc: 56117

Thomas Schneider <qsx@chaotikum.eu> writes:

> Dear maintainers,
>
> With “classic” X11 support in Emacs and GTK (probably the others, too),
> pressing the keypad separator ("," on, e.g., a german keyboard layout,
> "." on most others), gave emacs the key <kp-separator>.  With pgtk, this
> is no longer the case.

This is a known problem with several GTK input methods.  There is
nothing we can do.  You can disable using the GTK input method system by
running (pgtk-use-im-context nil), but quite obviously input methods and
the compose key will no longer work.

If you are using X Windows, this, along with many other problems, is why
you should not be using the PGTK port.  Contrary to popular belief, the
"classic" X support is not slower than the PGTK port (in fact, it is
often faster), and has much better support for the X window system,
including features that are simply absent on PGTK, such as support for
drag-and-drop.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Kangas @ 2022-06-22 20:44 UTC (permalink / raw)
  To: Po Lu; +Cc: 56117, Thomas Schneider

Po Lu <luangruo@yahoo.com> writes:

> This is a known problem with several GTK input methods.  There is
> nothing we can do.

Is this bug a wontfix, then?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-23  0:44 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 56117, Thomas Schneider

Stefan Kangas <stefan@marxist.se> writes:

> Is this bug a wontfix, then?

Not exactly, but it's a duplicate of bug#55660 and bug#53200, and
countless others.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-23  7:51 UTC (permalink / raw)
  To: 56117; +Cc: luangruo, stefan, qsx

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

>> Is this bug a wontfix, then?
>
> Not exactly, but it's a duplicate of bug#55660 and bug#53200, and
> countless others.

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-23  8:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 56117, stefan, qsx

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

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2022-06-23  8:28 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, stefan, 56117, qsx

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-23  8:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stefan, 56117, qsx

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.

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

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2022-06-23  9:49 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, stefan, 56117, qsx

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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-24  5:58                   ` Kévin Le Gouguec
  0 siblings, 2 replies; 15+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-23 10:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stefan, 56117, qsx

Eli Zaretskii <eliz@gnu.org> writes:

> And there's absolutely no way for Emacs to get at the original keys?

It can by turning the input method off, but as a result any features
provided by them will no longer work.

Most users prefer working input methods to those few rare keys, so it is
on by default.

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

I feel the same way, but didn't find anything.

> 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?

No, we don't have such a feature yet.  But it would be possible to
implement it.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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-24  5:58                   ` Kévin Le Gouguec
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2022-06-23 10:19 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, stefan, 56117, qsx

> 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 18:02:35 +0800
> 
> > 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?
> 
> No, we don't have such a feature yet.  But it would be possible to
> implement it.

What I meant was a simple enough key sequence to turn the input method
off and on.  If we can do that from Emacs, maybe we should provide
such a feature, it could alleviate the pain in at least some cases.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 1 reply; 15+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-23 11:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stefan, 56117, qsx

Eli Zaretskii <eliz@gnu.org> writes:

> What I meant was a simple enough key sequence to turn the input method
> off and on.  If we can do that from Emacs, maybe we should provide
> such a feature, it could alleviate the pain in at least some cases.

Which key sequence would you suggest binding to such a command?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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
  0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2022-06-23 13:00 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, stefan, 56117, qsx

> 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 19:37:15 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What I meant was a simple enough key sequence to turn the input method
> > off and on.  If we can do that from Emacs, maybe we should provide
> > such a feature, it could alleviate the pain in at least some cases.
> 
> Which key sequence would you suggest binding to such a command?

I don't know.  Is "C-x C-\" available?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  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-24  5:58                   ` Kévin Le Gouguec
  2022-06-24 16:43                     ` Kévin Le Gouguec
  1 sibling, 1 reply; 15+ messages in thread
From: Kévin Le Gouguec @ 2022-06-24  5:58 UTC (permalink / raw)
  To: 56117; +Cc: Eli Zaretskii

(Taken off-list because I'd rather limit the noise; I'm very likely
missing something)

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> And there's absolutely no way for Emacs to get at the original keys?
>
> It can by turning the input method off, but as a result any features
> provided by them will no longer work.

I'm a bit confused by that statement; you may remember that silly
experiment I ran in bug#52795?

https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;msg=17;filename=goof.patch;bug=52795

Po Lu <luangruo@yahoo.com> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> AFAICT Emacs receives enough information to see S-SPC?
>
> Yes, but after going through an input method module the S-SPC is lost.
>
>> No idea how easy it would be to pass on that information to the rest
>> of Emacs.
>
> Not easy, if we want to keep input methods (which GTK uses to implement
> the compose key) working.

At the time that left me with the impression that in principle, Emacs
could record what it received before "going through an input method" and
recover the lost information after the input method did its (bad) job;
in practice I assume that would be a very horrible kludge and a
nightmare to maintain.

Was that impression correct?  I'm not pushing for such a kludge; just
wondering if it's in the realm of possibility.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#56117: 29.0.50; pgtk does not distinguish between <kp-separator> and "."/","
  2022-06-24  5:58                   ` Kévin Le Gouguec
@ 2022-06-24 16:43                     ` Kévin Le Gouguec
  0 siblings, 0 replies; 15+ messages in thread
From: Kévin Le Gouguec @ 2022-06-24 16:43 UTC (permalink / raw)
  To: 56117

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> (Taken off-list because I'd rather limit the noise; I'm very likely
> missing something)

(Note to self: code a hook that looks for any parenthesized sentence
containing the phrase "off-list" before sending, and checks that indeed,
no list is among the recipients 🤦)





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-06-24 16:43 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.