GNU bug report logs -
#65068
29.1; xkb-interception interaction causes problems with key combinations
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65068 in the body.
You can then email your comments to 65068 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Sat, 05 Aug 2023 08:53:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alexander Prähauser <alexander.praehauser <at> gmx.at>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 05 Aug 2023 08:53:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I'm using the interception-`dual-function-keys`-plugin
https://gitlab.com/interception/linux/plugins/dual-function-keys
for my keyboard layout. In version 28.2 it worked perfectly, but
now, if I try to use combinations using keys that have
a dual function, the combination breaks off sending the wrong
signals. For instance, my CapsLock key has a dual function,
sending a F15 (XF86Launch5) if tapped and acting as the
apostrophe-key (AC11 in xkb) if held, which is configured in xkb
to act as an xkb level 3 modifier. However, now when I try to use
CapsLock for a key combination using a level 3 symbol, for
instance if I hold Control, then press CapsLock, it seems to send
simply the apostrophe-key, so that I receive the
message "C-' is undefined" and the key sequence is broken off. If
I continue to hold both Control and CapsLock, it seems
to access level 3 normally though, so that I can still use
combinations consisting of C-[level 3 character]. If I only want
to access a level 3 symbol by holding CapsLock, it works normally,
it seems
only combinations are affected. While typing this message I
noticed an even weirder thing: my F-key is configured to
have "a" on level and "Right" on level 5, and Rightalt is
configured to act as a level 5 modifier if held, and if I
press the F key normally or while holding Rightalt this works, but
if I first hold Control, then Rightalt, then tap the
F-key, it seems to interpret the result as C-f, even though on no
xkb-level the F-key is configured to actually send f.
The problem persists if I instead build the latest Emacs-version
(30.1) from Github, but vanishes if I downgrade to
28.2. It also persists if I start Emacs without loading the init
file.
In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8)
Windowing system distributor 'The X.Org Foundation', version
11.0.12301002
System Description: Arch Linux
Configured using:
'configure --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib
--with-tree-sitter --localstatedir=/var --with-cairo
--disable-build-details --with-harfbuzz --with-libsystemd
--with-modules --with-x-toolkit=gtk3 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs
-flto=auto'
'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
-flto=auto''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT
MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE
XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
winner-mode: t
mu4easy-mode: t
org-msg-mode: t
mu4e-column-faces-mode: t
mu4e-modeline-mode: t
global-edit-server-edit-mode: t
helm-epa-mode: t
helm-top-poll-mode: t
helm-adaptive-mode: t
recentf-mode: t
windmove-mode: t
backward-forward-mode: t
dynamic-completion-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
electric-pair-mode: t
yas-global-mode: t
yas-minor-mode: t
helm-mode: t
helm-minibuffer-history-mode: t
helm-ff-icon-mode: t
shell-dirtrack-mode: t
helm-popup-tip-mode: t
TeX-PDF-mode: t
global-auto-complete-mode: t
auto-complete-mode: t
savehist-mode: t
projectile-mode: t
minibuffer-depth-indicate-mode: t
icicle-mode: t
Info-breadcrumbs-in-mode-line-mode: t
global-undo-tree-mode: t
async-bytecomp-package-mode: t
override-global-mode: t
desktop-save-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
global-prettify-symbols-mode: t
prettify-symbols-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
global-visual-line-mode: t
visual-line-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
~/.emacs.d/site-lisp/icicles/dired+ hides
~/.emacs.d/site-lisp/dired+
~/.emacs.d/site-lisp/icicles/bookmark+ hides
/home/alex/.emacs.d/elpa/bookmark+-20230325.160624/bookmark+
/home/alex/.emacs.d/elpa/transient-20230723.1411/transient hides
/usr/share/emacs/29.1/lisp/transient
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package
hides /usr/share/emacs/29.1/lisp/use-package/use-package
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-lint
hides /usr/share/emacs/29.1/lisp/use-package/use-package-lint
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-jump
hides /usr/share/emacs/29.1/lisp/use-package/use-package-jump
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-ensure
hides /usr/share/emacs/29.1/lisp/use-package/use-package-ensure
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-diminish
hides /usr/share/emacs/29.1/lisp/use-package/use-package-diminish
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-delight
hides /usr/share/emacs/29.1/lisp/use-package/use-package-delight
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-core
hides /usr/share/emacs/29.1/lisp/use-package/use-package-core
/home/alex/.emacs.d/elpa/use-package-20230426.2324/use-package-bind-key
hides /usr/share/emacs/29.1/lisp/use-package/use-package-bind-key
/home/alex/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides
/usr/share/emacs/29.1/lisp/use-package/bind-key
Features:
(shadow view emacsbug winner face-remap tramp-archive tramp-gvfs
tramp-cache time-stamp zeroconf helm-command helm-elisp
helm-eval edebug debug backtrace mu4easy org-msg htmlize gnus-msg
gnus-cite helm-mu mu4e-alert time ht dash s alert
log4e gntp mu4e-column-faces inline mu4e-contrib eshell esh-cmd
esh-ext esh-opt esh-proc esh-io esh-arg esh-module
esh-groups esh-util mu4e-icalendar gnus-icalendar org-capture
icalendar diary-lib diary-loaddefs mu4e mu4e-org
mu4e-notification notifications mu4e-main mu4e-view gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range
gnus-win gnus nnheader range mu4e-headers mu4e-compose mu4e-draft
mu4e-actions smtpmail mu4e-search mu4e-lists
mu4e-bookmarks mu4e-mark mu4e-message shr pixel-fill kinsoku
url-file svg dom flow-fill mule-util mu4e-contacts
mu4e-update mu4e-folders mu4e-context mu4e-query-items mu4e-server
mu4e-modeline mu4e-vars mu4e-helpers mu4e-config
mu4e-window ido message sendmail yank-media puny rfc822 mml
mml-sec gnus-util mailabbrev mail-utils gmm-utils mailheader
mu4e-obsolete edit-server finder-inf init-helm helm-epa
all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons helm-sys helm-adaptive isearch+
isearch-prop color recentf tree-widget windmove epa-file
backward-forward completion display-line-numbers elec-pair
wc-mode quelpa-use-package quelpa mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr yasnippet-snippets yasnippet cdlatex reftex
reftex-loaddefs reftex-vars cl-extra helm-dired-history helm-mode
helm-misc helm-files tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell parse-time iso8601
helm-buffers helm-occur helm-tags helm-locate helm-grep
helm-regexp helm-utils helm-help helm-types auto-install
auto-complete-auctex latex latex-flymake flymake-proc flymake
warnings tex-ispell tex-style tex dbus xml crm texmathp
ac-math math-symbol-lists auto-complete-config auto-complete popup
epa epg rfc6068 epg-config yaml-mode auto-dictionary
flyspell-correct-helm flyspell-correct flyspell ispell gnus-dired
dired-quick-sort hydra lv savehist ls-lisp projectile
project lisp-mnt grep compile ibuf-ext mb-depth facemenu
two-column ibuffer ibuffer-loaddefs icicles icicles-mode dired+
image-file image-converter dired-aux icicles-cmd2 icicles-cmd1
icicles-mcmd image-dired image-dired-tags
image-dired-external image-dired-util doremi icicles-fn
icicles-var apropos-fn+var apropos icicles-opt ffap- ffap
fuzzy-match cus-theme cus-edit cus-load menu-bar+ misc-cmds rect
bookmark+ bookmark+-key bookmark+-bmu info+ fit-frame
help-fns+ wid-edit+ help-fns radix-tree bookmark+-lit pp+
help-mode derived crosshairs col-highlight vline hl-line+
hl-line bookmark+-1 bookmark+-mac bookmark text-property-search pp
thingatpt+ thingatpt icicles-face hexrgb mime-w3m w3m
doc-view filenotify jka-compr image-mode exif timezone w3m-hist
bookmark-w3m w3m-ems wid-edit w3m-favicon w3m-image
w3m-fb tab-line w3m-proc w3m-util dired-x dired dired-loaddefs
ox-odt rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
ox-latex ox-icalendar org-agenda ox-html table ox-ascii
ox-publish ox org-element org-persist xdg org-id org-refile org ob
ob-tangle ob-ref ob-lob ob-table org-macro org-src
ob-comint org-pcomplete pcomplete comint ansi-osc ansi-color
org-list org-footnote org-faces org-entities time-date
noutline outline icons ob-emacs-lisp org-table org-keys
org-loaddefs find-func cal-menu calendar cal-loaddefs avl-tree
generator ol oc ob-exp ob-core org-cycle org-fold org-fold-core
org-compat ob-eval org-version org-macs format-spec
ace-jump-mode advice undo-tree diff queue helm
helm-global-bindings edmacro kmacro helm-info ring helm-core
async-bytecomp helm-source helm-multi-match helm-lib async
use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core desktop frameset icicles-install cl
modus-vivendi-theme modus-themes ac-math-autoloads tex-site
auto-complete-auctex-autoloads auto-complete-sage-autoloads
auto-complete-autoloads auto-dictionary-autoloads
math-symbol-lists-autoloads helm-easymenu rx pcase w3m-load info
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 password-cache json subr-x map
byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win
x-win term/common-win x-dnd 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 seq 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 theme-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 dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)
Memory information:
((conses 16 1084888 70575)
(symbols 48 64992 2)
(strings 32 309699 10624)
(string-bytes 1 9054677)
(vectors 16 104759)
(vector-slots 8 1305888 62372)
(floats 8 1013 357)
(intervals 56 1703 365)
(buffers 984 20))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 09 Aug 2023 00:04:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> I'm using the interception-`dual-function-keys`-plugin
>
> https://gitlab.com/interception/linux/plugins/dual-function-keys
>
> for my keyboard layout. In version 28.2 it worked perfectly, but
> now, if I try to use combinations using keys that have
> a dual function, the combination breaks off sending the wrong
> signals. For instance, my CapsLock key has a dual function,
> sending a F15 (XF86Launch5) if tapped and acting as the
> apostrophe-key (AC11 in xkb) if held, which is configured in xkb
> to act as an xkb level 3 modifier.
Which virtual modifier key have you assigned to the apostrophe key?
> However, now when I try to use
> CapsLock for a key combination using a level 3 symbol, for
> instance if I hold Control, then press CapsLock, it seems to send
> simply the apostrophe-key, so that I receive the
> message "C-' is undefined" and the key sequence is broken off. If
> I continue to hold both Control and CapsLock, it seems
> to access level 3 normally though, so that I can still use
> combinations consisting of C-[level 3 character]. If I only want
> to access a level 3 symbol by holding CapsLock, it works normally,
> it seems
> only combinations are affected. While typing this message I
> noticed an even weirder thing: my F-key is configured to
> have "a" on level and "Right" on level 5, and Rightalt is
> configured to act as a level 5 modifier if held, and if I
> press the F key normally or while holding Rightalt this works, but
> if I first hold Control, then Rightalt, then tap the
> F-key, it seems to interpret the result as C-f, even though on no
> xkb-level the F-key is configured to actually send f.
>
> The problem persists if I instead build the latest Emacs-version
> (30.1) from Github
Nit: Emacs is not developed on GitHub, but on Savannah:
https://git.sv.gnu.org/cgit/emacs.git
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Tue, 15 Aug 2023 15:05:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Sorry for the late reply.
> Which virtual modifier key have you assigned to the apostrophe
> key?
I've made the apostrophe key (AC11 in xkb) a level 3 switch
through the following function:
> // The AC11 key (while pressed) chooses the third shift level.
> partial modifier_keys
> xkb_symbols "ac11_switch" {
> key <AC11> {
> type[Group1]="ONE_LEVEL",
> symbols[Group1] = [ ISO_Level3_Shift ]
> };
> };
If tapped it sends an F14 signal (which I use in Emacs to insert
math symbols in cdlatex).
> Nit: Emacs is not developed on GitHub, but on Savannah:
I see. What I meant was that I built it using the emacs-git entry
in the AUR.
Po Lu [2023-08-09 Wed 08:02] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> I'm using the interception-`dual-function-keys`-plugin
>>
>> https://gitlab.com/interception/linux/plugins/dual-function-keys
>>
>> for my keyboard layout. In version 28.2 it worked perfectly,
>> but
>> now, if I try to use combinations using keys that have
>> a dual function, the combination breaks off sending the wrong
>> signals. For instance, my CapsLock key has a dual function,
>> sending a F15 (XF86Launch5) if tapped and acting as the
>> apostrophe-key (AC11 in xkb) if held, which is configured in
>> xkb
>> to act as an xkb level 3 modifier.
>
> Which virtual modifier key have you assigned to the apostrophe
> key?
>
>> However, now when I try to use
>> CapsLock for a key combination using a level 3 symbol, for
>> instance if I hold Control, then press CapsLock, it seems to
>> send
>> simply the apostrophe-key, so that I receive the
>> message "C-' is undefined" and the key sequence is broken
>> off. If
>> I continue to hold both Control and CapsLock, it seems
>> to access level 3 normally though, so that I can still use
>> combinations consisting of C-[level 3 character]. If I only
>> want
>> to access a level 3 symbol by holding CapsLock, it works
>> normally,
>> it seems
>> only combinations are affected. While typing this message I
>> noticed an even weirder thing: my F-key is configured to
>> have "a" on level and "Right" on level 5, and Rightalt is
>> configured to act as a level 5 modifier if held, and if I
>> press the F key normally or while holding Rightalt this works,
>> but
>> if I first hold Control, then Rightalt, then tap the
>> F-key, it seems to interpret the result as C-f, even though on
>> no
>> xkb-level the F-key is configured to actually send f.
>>
>> The problem persists if I instead build the latest
>> Emacs-version
>> (30.1) from Github
>
> Nit: Emacs is not developed on GitHub, but on Savannah:
>
> https://git.sv.gnu.org/cgit/emacs.git
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 16 Aug 2023 01:31:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> Sorry for the late reply.
>
>> Which virtual modifier key have you assigned to the apostrophe key?
>
> I've made the apostrophe key (AC11 in xkb) a level 3 switch through
> the following function:
>
>> // The AC11 key (while pressed) chooses the third shift level.
>> partial modifier_keys
>> xkb_symbols "ac11_switch" {
>> key <AC11> {
>> type[Group1]="ONE_LEVEL",
>> symbols[Group1] = [ ISO_Level3_Shift ]
>> };
>> };
>
> If tapped it sends an F14 signal (which I use in Emacs to insert math
> symbols in cdlatex).
I guess I still don't fully understand your XKB configuration. Having
access to the complete XKB configuration on your X server would be a
great help to that end.
Would you please run:
xkbcomp -xkb $DISPLAY
and attach each generated *.xkb file?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 16 Aug 2023 07:59:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 65068 <at> debbugs.gnu.org (full text, mbox):
[server-0.xkb (file, attachment)]
[Message part 2 (text/plain, inline)]
Note that I the command produced the following warning:
> Warning: Could not load keyboard geometry for :0
> BadName (named color or font does not exist)
> Resulting keymap file will not describe
> geometry
The keymap seems alright though. I've been modifying the
adnw-keymap because making a new one didn't really work with
the modifiers. Here is also my dual-function-keys config:
[my-mappings.yaml (file, attachment)]
[Message part 4 (text/plain, inline)]
Po Lu [2023-08-16 Wed 09:29] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> Sorry for the late reply.
>>
>>> Which virtual modifier key have you assigned to the apostrophe
>>> key?
>>
>> I've made the apostrophe key (AC11 in xkb) a level 3 switch
>> through
>> the following function:
>>
>>> // The AC11 key (while pressed) chooses the third shift level.
>>> partial modifier_keys
>>> xkb_symbols "ac11_switch" {
>>> key <AC11> {
>>> type[Group1]="ONE_LEVEL",
>>> symbols[Group1] = [ ISO_Level3_Shift ]
>>> };
>>> };
>>
>> If tapped it sends an F14 signal (which I use in Emacs to
>> insert math
>> symbols in cdlatex).
>
> I guess I still don't fully understand your XKB configuration.
> Having
> access to the complete XKB configuration on your X server would
> be a
> great help to that end.
>
> Would you please run:
>
> xkbcomp -xkb $DISPLAY
>
> and attach each generated *.xkb file?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 16 Aug 2023 08:06:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 65068 <at> debbugs.gnu.org (full text, mbox):
I just noticed that the last line in the dual-function-keys config
contains an x I must have inadvertantly written in at
some point and not noticed because I hadn't restarted udevmon
since. Please remove that x if you try it out, otherwise
it will produce an error.
Alexander Prähauser [2023-08-16 Wed 09:50] wrote:
> [1. xkb file --- text/plain; server-0.xkb]...
>
>
> Note that I the command produced the following warning:
>
>> Warning: Could not load keyboard geometry for :0
>> BadName (named color or font does not exist)
>> Resulting keymap file will not describe
>> geometry
>
> The keymap seems alright though. I've been modifying the
> adnw-keymap
> because making a new one didn't really work with
> the modifiers. Here is also my dual-function-keys config:
>
> [3. dual function keys config --- text/plain;
> my-mappings.yaml]...
>
>
>
> Po Lu [2023-08-16 Wed 09:29] wrote:
>
>> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>>
>>> Sorry for the late reply.
>>>
>>>> Which virtual modifier key have you assigned to the
>>>> apostrophe
>>>> key?
>>>
>>> I've made the apostrophe key (AC11 in xkb) a level 3 switch
>>> through
>>> the following function:
>>>
>>>> // The AC11 key (while pressed) chooses the third shift
>>>> level.
>>>> partial modifier_keys
>>>> xkb_symbols "ac11_switch" {
>>>> key <AC11> {
>>>> type[Group1]="ONE_LEVEL",
>>>> symbols[Group1] = [ ISO_Level3_Shift ]
>>>> };
>>>> };
>>>
>>> If tapped it sends an F14 signal (which I use in Emacs to
>>> insert
>>> math
>>> symbols in cdlatex).
>>
>> I guess I still don't fully understand your XKB
>> configuration. Having
>> access to the complete XKB configuration on your X server would
>> be a
>> great help to that end.
>>
>> Would you please run:
>>
>> xkbcomp -xkb $DISPLAY
>>
>> and attach each generated *.xkb file?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 16 Aug 2023 12:52:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Thank you for providing these details. Sadly, I still don't understand
how xkb-interception operates, so please also run:
xinput test-xi2
then type the following sequence of keys with the window `xinput'
displays focused:
press and release Caps Lock
press and release Ctrl
press Ctrl, then Caps Lock, before releasing Ctrl
and send me the output of `xinput'. Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 16 Aug 2023 14:10:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Since I normally use Space as Ctrl with interception I did the
second two steps twice, with Space instead of Ctrl the
second time. The last two events were me closing the window using
my mouse:
> [alex <at> Archlaptop ~]$ xinput test-xi2
> WARNING: running xinput against an Xwayland server. See the
> xinput man page for details.
> ⎡ Virtual core pointer id=2 [master
> pointer (3)]
> ⎜ ↳ Virtual core XTEST pointer id=4
> [slave pointer (2)]
> ⎜ ↳ xwayland-pointer:15 id=6
> [slave pointer (2)]
> ⎜ ↳ xwayland-relative-pointer:15 id=7
> [slave pointer (2)]
> ⎜ ↳ xwayland-pointer-gestures:15 id=8
> [slave pointer (2)]
> ⎣ Virtual core keyboard id=3 [master
> keyboard (2)]
> ↳ Virtual core XTEST keyboard id=5
> [slave keyboard (3)]
> ↳ xwayland-keyboard:15 id=9
> [slave keyboard (3)]
> EVENT type 9 (FocusIn)
> device: 3 (3)
> time: 7243828
> windows: root 0x3cf event 0xc00001 child 0x0
> mode: NotifyNormal (detail NotifyNonlinear)
> flags: [same screen]
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> root x/y: 268.00 / 153.00
> event x/y: 178.00 / -20.00
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7243838
> detail: 36
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7243838
> detail: 36
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7244995
> detail: 48
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7244995
> detail: 48
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7245351
> detail: 48
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7245351
> detail: 48
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0x80 effective: 0x80
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7246301
> detail: 37
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7246301
> detail: 37
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7246520
> detail: 37
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7246520
> detail: 37
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7247580
> detail: 37
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7247580
> detail: 37
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7247975
> detail: 48
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7247975
> detail: 48
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7248180
> detail: 48
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7248180
> detail: 48
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0x80 effective: 0x80
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7248552
> detail: 37
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7248552
> detail: 37
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7249763
> detail: 105
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7249763
> detail: 105
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7250099
> detail: 105
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7250099
> detail: 105
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0x4 effective: 0x4
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7251504
> detail: 105
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7251504
> detail: 105
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0 effective: 0
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 13 (RawKeyPress)
> device: 3 (9)
> time: 7252051
> detail: 48
> valuators:
> EVENT type 2 (KeyPress)
> device: 3 (9)
> time: 7252051
> detail: 48
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0x4 effective: 0x4
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7252342
> detail: 48
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7252342
> detail: 48
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0x84 effective: 0x84
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 14 (RawKeyRelease)
> device: 3 (9)
> time: 7252568
> detail: 105
> valuators:
> EVENT type 3 (KeyRelease)
> device: 3 (9)
> time: 7252568
> detail: 105
> flags:
> root: 268.00/153.00
> event: 178.00/-20.00
> buttons:
> modifiers: locked 0 latched 0 base 0x4 effective: 0x4
> group: locked 0 latched 0 base 0 effective: 0
> valuators:
> windows: root 0x3cf event 0xc00001 child 0x0
> EVENT type 15 (RawButtonPress)
> device: 2 (7)
> time: 7256662
> detail: 1
> flags:
> valuators:
> EVENT type 16 (RawButtonRelease)
> device: 2 (7)
> time: 7256802
> detail: 1
> flags:
> valuators:
> X connection to :0 broken (explicit kill or server shutdown).
Po Lu [2023-08-16 Wed 20:51] wrote:
> Thank you for providing these details. Sadly, I still don't
> understand
> how xkb-interception operates, so please also run:
>
> xinput test-xi2
>
> then type the following sequence of keys with the window
> `xinput'
> displays focused:
>
> press and release Caps Lock
> press and release Ctrl
> press Ctrl, then Caps Lock, before releasing Ctrl
>
> and send me the output of `xinput'. Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 17 Aug 2023 01:10:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Thanks. Please instrument handle_one_xevent in xterm.c as follows:
diff --git a/src/xterm.c b/src/xterm.c
index 6a1642ff56e..a199bae9f16 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -23886,6 +23886,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
if (!XkbTranslateKeyCode (dpyinfo->xkb_desc, keycode,
xkb_state, &mods_rtrn, &keysym))
goto XI_OTHER;
+
+ fprintf (stderr, "keycode: %d, keysym: %d, %u\n", keycode,
+ (int) keysym, state);
}
else
{
then tell me what is printed when you press Caps Lock (which appears to
be directly translated to AC11 prior to it ever being registered by the
X server), and also if the text changes if you press Caps Lock in
conjunction with Ctrl.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 17 Aug 2023 02:42:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 65068 <at> debbugs.gnu.org (full text, mbox):
How do I do that? I tried putting the code into a bash script and
it says `diff: unrecognized option '--git'`.
Po Lu [2023-08-17 Thu 09:09] wrote:
> Thanks. Please instrument handle_one_xevent in xterm.c as
> follows:
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 6a1642ff56e..a199bae9f16 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -23886,6 +23886,9 @@ handle_one_xevent (struct x_display_info
> *dpyinfo,
> if (!XkbTranslateKeyCode (dpyinfo->xkb_desc,
> keycode,
> xkb_state, &mods_rtrn,
> &keysym))
> goto XI_OTHER;
> +
> + fprintf (stderr, "keycode: %d, keysym: %d,
> %u\n", keycode,
> + (int) keysym, state);
> }
> else
> {
>
> then tell me what is printed when you press Caps Lock (which
> appears to
> be directly translated to AC11 prior to it ever being registered
> by the
> X server), and also if the text changes if you press Caps Lock
> in
> conjunction with Ctrl.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 17 Aug 2023 02:47:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> How do I do that? I tried putting the code into a bash script and
> it says `diff: unrecognized option '--git'`.
You should save the entire diff into the kill ring, run:
git apply -
then type:
C-y
C-q C-d RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 17 Aug 2023 03:31:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 65068 <at> debbugs.gnu.org (full text, mbox):
It says
> error: src/xterm.c: No such file or directory
I also can't find xterm.c on my system, though I have xterm
installed.
Po Lu [2023-08-17 Thu 10:45] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> How do I do that? I tried putting the code into a bash script
>> and
>> it says `diff: unrecognized option '--git'`.
>
> You should save the entire diff into the kill ring, run:
>
> git apply -
>
> then type:
>
> C-y
> C-q C-d RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 17 Aug 2023 04:42:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> It says
>
>> error: src/xterm.c: No such file or directory
>
> I also can't find xterm.c on my system, though I have xterm installed.
Did you run that within the Git repository where your Emacs checkout
resides?
src/xterm.c is an Emacs source file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Sat, 19 Aug 2023 13:57:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 65068 <at> debbugs.gnu.org (full text, mbox):
After I couldn't resolve the keyboard issue I reinstalled an old
binary version from the Arch archives but I've now
downloaded the Emacs source files and tried to apply the patch in
that local directory. However, I get the error
message:
> [alex <at> Archlaptop emacs]$ git apply -
> diff --git a/src/xterm.c b/src/xterm.c
> index 6a1642ff56e..a199bae9f16 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -23886,6 +23886,9 @@ handle_one_xevent (struct x_display_info
> *dpyinfo,
> if (!XkbTranslateKeyCode (dpyinfo->xkb_desc,
> keycode,
> xkb_state, &mods_rtrn,
> &keysym))
> goto XI_OTHER;
> +
> + fprintf (stderr, "keycode: %d, keysym: %d,
> %u\n", keycode,
> + (int) keysym, state);
> }
> else
> {
> error: patch failed: src/xterm.c:23886
> error: src/xterm.c: patch does not apply
I tried again after compiling Emacs with make and got the same
error. I didn't install that Emacs version though so not
to overwrite my current one. If necessary I can install a
source-compiled Emacs version on another system though, but I
wanted to ask before if that might be useful.
Po Lu [2023-08-17 Thu 12:41] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> It says
>>
>>> error: src/xterm.c: No such file or directory
>>
>> I also can't find xterm.c on my system, though I have xterm
>> installed.
>
> Did you run that within the Git repository where your Emacs
> checkout
> resides?
>
> src/xterm.c is an Emacs source file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 23 Aug 2023 11:04:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 65068 <at> debbugs.gnu.org (full text, mbox):
So, what should I do next?
Alexander Prähauser [2023-08-19 Sat 15:35] wrote:
> After I couldn't resolve the keyboard issue I reinstalled an old
> binary version from the Arch archives but I've now
> downloaded the Emacs source files and tried to apply the patch
> in that
> local directory. However, I get the error
> message:
>
>> [alex <at> Archlaptop emacs]$ git apply -
>> diff --git a/src/xterm.c b/src/xterm.c
>> index 6a1642ff56e..a199bae9f16 100644
>> --- a/src/xterm.c
>> +++ b/src/xterm.c
>> @@ -23886,6 +23886,9 @@ handle_one_xevent (struct
>> x_display_info
>> *dpyinfo,
>> if (!XkbTranslateKeyCode (dpyinfo->xkb_desc,
>> keycode,
>> xkb_state, &mods_rtrn,
>> &keysym))
>> goto XI_OTHER;
>> +
>> + fprintf (stderr, "keycode: %d, keysym: %d,
>> %u\n",
>> keycode,
>> + (int) keysym, state);
>> }
>> else
>> {
>> error: patch failed: src/xterm.c:23886
>> error: src/xterm.c: patch does not apply
>
> I tried again after compiling Emacs with make and got the same
> error. I didn't install that Emacs version though so not
> to overwrite my current one. If necessary I can install a
> source-compiled Emacs version on another system though, but I
> wanted to ask before if that might be useful.
>
> Po Lu [2023-08-17 Thu 12:41] wrote:
>
>> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>>
>>> It says
>>>
>>>> error: src/xterm.c: No such file or directory
>>>
>>> I also can't find xterm.c on my system, though I have xterm
>>> installed.
>>
>> Did you run that within the Git repository where your Emacs
>> checkout
>> resides?
>>
>> src/xterm.c is an Emacs source file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 23 Aug 2023 11:40:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> So, what should I do next?
Assuming that you've applied the patch, press the problematic key
sequence and reply with the subsequent printouts.
TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Wed, 23 Aug 2023 14:13:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 65068 <at> debbugs.gnu.org (full text, mbox):
I've built emacs on another system with the same keyboard
configuration, then applied the patch, then recompiled it and
started it from the terminal. The problem persists, but I got
outputs in the console everytime I pressed a key, I'm
assuming due to the patch. The following is the output I got from
tapping Space, then holding Space (so that it
functions as Ctrl), then holding Space and tapping CapsLock, then
holding Space, holding CapsLock and tapping the U-key
(which should translate to the keyboard-sequence C-ö):
> keycode: 105, keysym: 65508, 0
> keycode: 65, keysym: 32, 0
> keycode: 105, keysym: 65508, 0
> keycode: 105, keysym: 65508, 0
> keycode: 48, keysym: 65027, 4
> keycode: 192, keysym: 269025093, 4
> keycode: 105, keysym: 65508, 0
> keycode: 48, keysym: 65027, 4
> keycode: 30, keysym: 246, 132
Po Lu [2023-08-23 Wed 19:39] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> So, what should I do next?
>
> Assuming that you've applied the patch, press the problematic
> key
> sequence and reply with the subsequent printouts.
>
> TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 24 Aug 2023 00:02:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> I've built emacs on another system with the same keyboard
> configuration, then applied the patch, then recompiled it and
> started it from the terminal. The problem persists, but I got outputs
> in the console everytime I pressed a key, I'm
> assuming due to the patch. The following is the output I got from
> tapping Space, then holding Space (so that it
> functions as Ctrl), then holding Space and tapping CapsLock, then
> holding Space, holding CapsLock and tapping the U-key
> (which should translate to the keyboard-sequence C-ö):
Thanks; however, the keys I asked you to type were:
press and release Caps Lock
press and release Ctrl
press Ctrl, then Caps Lock, before releasing Ctrl
I don't understand the pertinence of a ``U-key'' here, nor which key
that is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 24 Aug 2023 09:12:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 65068 <at> debbugs.gnu.org (full text, mbox):
The significance of the U-key is that when I press
Space-CapsLock-U (or any other key, I think), it doesn't send the
signal
that is configured by xkb but the corresponding key of the default
English keymap (u for the U-key), which really
shouldn't happen. Anyway, here the output after pressing the
sequence you wanted:
keycode: 48, keysym: 65027, 0
keycode: 192, keysym: 269025093, 0
keycode: 37, keysym: 65507, 0
keycode: 37, keysym: 65507, 0
keycode: 48, keysym: 65027, 0
keycode: 192, keysym: 269025093, 0
Po Lu [2023-08-24 Thu 08:00] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> I've built emacs on another system with the same keyboard
>> configuration, then applied the patch, then recompiled it and
>> started it from the terminal. The problem persists, but I got
>> outputs
>> in the console everytime I pressed a key, I'm
>> assuming due to the patch. The following is the output I got
>> from
>> tapping Space, then holding Space (so that it
>> functions as Ctrl), then holding Space and tapping CapsLock,
>> then
>> holding Space, holding CapsLock and tapping the U-key
>> (which should translate to the keyboard-sequence C-ö):
>
> Thanks; however, the keys I asked you to type were:
>
> press and release Caps Lock
> press and release Ctrl
> press Ctrl, then Caps Lock, before releasing Ctrl
>
> I don't understand the pertinence of a ``U-key'' here, nor which
> key
> that is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 24 Aug 2023 09:57:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> The significance of the U-key is that when I press Space-CapsLock-U
> (or any other key, I think), it doesn't send the signal
> that is configured by xkb but the corresponding key of the default
> English keymap (u for the U-key), which really
> shouldn't happen. Anyway, here the output after pressing the sequence
> you wanted:
>
> keycode: 48, keysym: 65027, 0
> keycode: 192, keysym: 269025093, 0
> keycode: 37, keysym: 65507, 0
> keycode: 37, keysym: 65507, 0 <- Control_R
> keycode: 48, keysym: 65027, 0 <- AC11, ISO_Level3_Shift
> keycode: 192, keysym: 269025093, <- XF86Launch5
This attests to Emacs registering the keysyms you meant it to. If
ISO_Level3_Shift is registered as a modifier key, it should not be
translated into keyboard input afterwards, let alone the original
apostrophe symbol.
Does this patch resolve your problems with typing level 3 characters
coupled with Control?
diff --git a/src/xterm.c b/src/xterm.c
index 6a1642ff56e..7391041ea0c 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -23734,6 +23734,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
ptrdiff_t i;
unsigned int old_state;
struct xi_device_t *device, *source;
+ bool is_modifier_key;
coding = Qlatin_1;
@@ -24175,17 +24176,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
/* Any "vendor-specific" key is ok. */
|| (keysym & (1 << 28))
|| (keysym != NoSymbol && nbytes == 0))
- && ! (IsModifierKey (keysym)
- /* The symbols from XK_ISO_Lock
- to XK_ISO_Last_Group_Lock
- don't have real modifiers but
- should be treated similarly to
- Mode_switch by Emacs. */
-#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
- || (XK_ISO_Lock <= keysym
- && keysym <= XK_ISO_Last_Group_Lock)
-#endif
- ))
+ && !is_modifier_key)
{
STORE_KEYSYM_FOR_DEBUG (keysym);
/* make_lispy_event will convert this to a symbolic
@@ -24204,7 +24195,11 @@ handle_one_xevent (struct x_display_info *dpyinfo,
STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
}
- if (nbytes)
+ /* Mind that NBYTES can be set even if KEYSYM
+ represents a modifier key, but that no character
+ events should be sent in that case. */
+
+ if (nbytes && !is_modifier_key)
{
inev.ie.kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
inev.ie.arg = make_unibyte_string (copy_bufptr, nbytes);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 24 Aug 2023 12:19:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 65068 <at> debbugs.gnu.org (full text, mbox):
It does seem to register the correct level shifts now, but it
seems to evaluate each key immediately after having been
pressed. For instance, when I press Space-CapsLock-U, this should
evaluate to C-; and it does, but this is the output
I'm receiving in-between:
<Control_R> is undefined
C-' is undefined
C-; is undefined
Po Lu [2023-08-24 Thu 17:56] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> The significance of the U-key is that when I press
>> Space-CapsLock-U
>> (or any other key, I think), it doesn't send the signal
>> that is configured by xkb but the corresponding key of the
>> default
>> English keymap (u for the U-key), which really
>> shouldn't happen. Anyway, here the output after pressing the
>> sequence
>> you wanted:
>>
>> keycode: 48, keysym: 65027, 0
>> keycode: 192, keysym: 269025093, 0
>> keycode: 37, keysym: 65507, 0
>> keycode: 37, keysym: 65507, 0 <- Control_R
>> keycode: 48, keysym: 65027, 0 <- AC11, ISO_Level3_Shift
>> keycode: 192, keysym: 269025093, <- XF86Launch5
>
> This attests to Emacs registering the keysyms you meant it to.
> If
> ISO_Level3_Shift is registered as a modifier key, it should not
> be
> translated into keyboard input afterwards, let alone the
> original
> apostrophe symbol.
>
> Does this patch resolve your problems with typing level 3
> characters
> coupled with Control?
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 6a1642ff56e..7391041ea0c 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -23734,6 +23734,7 @@ handle_one_xevent (struct x_display_info
> *dpyinfo,
> ptrdiff_t i;
> unsigned int old_state;
> struct xi_device_t *device, *source;
> + bool is_modifier_key;
>
> coding = Qlatin_1;
>
> @@ -24175,17 +24176,7 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> /* Any "vendor-specific" key is ok. */
> || (keysym & (1 << 28))
> || (keysym != NoSymbol && nbytes == 0))
> - && ! (IsModifierKey (keysym)
> - /* The symbols from XK_ISO_Lock
> - to XK_ISO_Last_Group_Lock
> - don't have real modifiers but
> - should be treated similarly to
> - Mode_switch by Emacs. */
> -#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
> - || (XK_ISO_Lock <= keysym
> - && keysym <=
> XK_ISO_Last_Group_Lock)
> -#endif
> - ))
> + && !is_modifier_key)
> {
> STORE_KEYSYM_FOR_DEBUG (keysym);
> /* make_lispy_event will convert this to a
> symbolic
> @@ -24204,7 +24195,11 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
> }
>
> - if (nbytes)
> + /* Mind that NBYTES can be set even if KEYSYM
> + represents a modifier key, but that no
> character
> + events should be sent in that case. */
> +
> + if (nbytes && !is_modifier_key)
> {
> inev.ie.kind =
> MULTIBYTE_CHAR_KEYSTROKE_EVENT;
> inev.ie.arg = make_unibyte_string
> (copy_bufptr, nbytes);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 24 Aug 2023 12:43:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> It does seem to register the correct level shifts now, but it seems to
> evaluate each key immediately after having been
> pressed. For instance, when I press Space-CapsLock-U, this should
> evaluate to C-; and it does, but this is the output
> I'm receiving in-between:
>
> <Control_R> is undefined
> C-' is undefined
> C-; is undefined
>
> Po Lu [2023-08-24 Thu 17:56] wrote:
>
>> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>>
>>> The significance of the U-key is that when I press Space-CapsLock-U
>>> (or any other key, I think), it doesn't send the signal
>>> that is configured by xkb but the corresponding key of the default
>>> English keymap (u for the U-key), which really
>>> shouldn't happen. Anyway, here the output after pressing the
>>> sequence
>>> you wanted:
>>>
>>> keycode: 48, keysym: 65027, 0
>>> keycode: 192, keysym: 269025093, 0
>>> keycode: 37, keysym: 65507, 0
>>> keycode: 37, keysym: 65507, 0 <- Control_R
>>> keycode: 48, keysym: 65027, 0 <- AC11, ISO_Level3_Shift
>>> keycode: 192, keysym: 269025093, <- XF86Launch5
>>
>> This attests to Emacs registering the keysyms you meant it to. If
>> ISO_Level3_Shift is registered as a modifier key, it should not be
>> translated into keyboard input afterwards, let alone the original
>> apostrophe symbol.
>>
>> Does this patch resolve your problems with typing level 3 characters
>> coupled with Control?
>>
>> diff --git a/src/xterm.c b/src/xterm.c
>> index 6a1642ff56e..7391041ea0c 100644
>> --- a/src/xterm.c
>> +++ b/src/xterm.c
>> @@ -23734,6 +23734,7 @@ handle_one_xevent (struct x_display_info
>> *dpyinfo,
>> ptrdiff_t i;
>> unsigned int old_state;
>> struct xi_device_t *device, *source;
>> + bool is_modifier_key;
>> coding = Qlatin_1;
>> @@ -24175,17 +24176,7 @@ handle_one_xevent (struct x_display_info
>> *dpyinfo,
>> /* Any "vendor-specific" key is ok. */
>> || (keysym & (1 << 28))
>> || (keysym != NoSymbol && nbytes == 0))
>> - && ! (IsModifierKey (keysym)
>> - /* The symbols from XK_ISO_Lock
>> - to XK_ISO_Last_Group_Lock
>> - don't have real modifiers but
>> - should be treated similarly to
>> - Mode_switch by Emacs. */
>> -#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
>> - || (XK_ISO_Lock <= keysym
>> - && keysym <= XK_ISO_Last_Group_Lock)
>> -#endif
>> - ))
>> + && !is_modifier_key)
>> {
>> STORE_KEYSYM_FOR_DEBUG (keysym);
>> /* make_lispy_event will convert this to a
>> symbolic
>> @@ -24204,7 +24195,11 @@ handle_one_xevent (struct x_display_info
>> *dpyinfo,
>> STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
>> }
>> - if (nbytes)
>> + /* Mind that NBYTES can be set even if KEYSYM
>> + represents a modifier key, but that no character
>> + events should be sent in that case. */
>> +
>> + if (nbytes && !is_modifier_key)
>> {
>> inev.ie.kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
>> inev.ie.arg = make_unibyte_string (copy_bufptr,
>> nbytes);
Please excuse my carelessness, I appear to have ommitted a chunk of the
diff:
diff --git a/src/xterm.c b/src/xterm.c
index 6a1642ff56e..4b2da066694 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -23734,6 +23734,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
ptrdiff_t i;
unsigned int old_state;
struct xi_device_t *device, *source;
+ bool is_modifier_key;
coding = Qlatin_1;
@@ -24091,6 +24092,18 @@ handle_one_xevent (struct x_display_info *dpyinfo,
goto xi_done_keysym;
}
+ is_modifier_key = (IsModifierKey (keysym)
+ /* The symbols from XK_ISO_Lock
+ to XK_ISO_Last_Group_Lock
+ don't have real modifiers but
+ should be treated similarly to
+ Mode_switch by Emacs. */
+#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
+ || (XK_ISO_Lock <= keysym
+ && keysym <= XK_ISO_Last_Group_Lock)
+#endif
+ );
+
/* Random non-modifier sorts of keysyms. */
if (((keysym >= XK_BackSpace && keysym <= XK_Escape)
|| keysym == XK_Delete
@@ -24175,17 +24188,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
/* Any "vendor-specific" key is ok. */
|| (keysym & (1 << 28))
|| (keysym != NoSymbol && nbytes == 0))
- && ! (IsModifierKey (keysym)
- /* The symbols from XK_ISO_Lock
- to XK_ISO_Last_Group_Lock
- don't have real modifiers but
- should be treated similarly to
- Mode_switch by Emacs. */
-#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
- || (XK_ISO_Lock <= keysym
- && keysym <= XK_ISO_Last_Group_Lock)
-#endif
- ))
+ && !is_modifier_key)
{
STORE_KEYSYM_FOR_DEBUG (keysym);
/* make_lispy_event will convert this to a symbolic
@@ -24204,7 +24207,11 @@ handle_one_xevent (struct x_display_info *dpyinfo,
STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
}
- if (nbytes)
+ /* Mind that NBYTES can be set even if KEYSYM
+ represents a modifier key, but that no character
+ events should be sent in that case. */
+
+ if (nbytes && !is_modifier_key)
{
inev.ie.kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
inev.ie.arg = make_unibyte_string (copy_bufptr, nbytes);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Thu, 24 Aug 2023 13:41:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Now when I press for instance Space, it doesn't seem to evaluate
immediately, but it does evaluate when I
press another dual-function-modified key. So if I press the same
sequence as below the first message doesn't appear but
the second one does.
Po Lu [2023-08-24 Thu 20:41] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> It does seem to register the correct level shifts now, but it
>> seems to
>> evaluate each key immediately after having been
>> pressed. For instance, when I press Space-CapsLock-U, this
>> should
>> evaluate to C-; and it does, but this is the output
>> I'm receiving in-between:
>>
>> <Control_R> is undefined
>> C-' is undefined
>> C-; is undefined
>>
>> Po Lu [2023-08-24 Thu 17:56] wrote:
>>
>>> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>>>
>>>> The significance of the U-key is that when I press
>>>> Space-CapsLock-U
>>>> (or any other key, I think), it doesn't send the signal
>>>> that is configured by xkb but the corresponding key of the
>>>> default
>>>> English keymap (u for the U-key), which really
>>>> shouldn't happen. Anyway, here the output after pressing the
>>>> sequence
>>>> you wanted:
>>>>
>>>> keycode: 48, keysym: 65027, 0
>>>> keycode: 192, keysym: 269025093, 0
>>>> keycode: 37, keysym: 65507, 0
>>>> keycode: 37, keysym: 65507, 0 <- Control_R
>>>> keycode: 48, keysym: 65027, 0 <- AC11, ISO_Level3_Shift
>>>> keycode: 192, keysym: 269025093, <- XF86Launch5
>>>
>>> This attests to Emacs registering the keysyms you meant it
>>> to. If
>>> ISO_Level3_Shift is registered as a modifier key, it should
>>> not be
>>> translated into keyboard input afterwards, let alone the
>>> original
>>> apostrophe symbol.
>>>
>>> Does this patch resolve your problems with typing level 3
>>> characters
>>> coupled with Control?
>>>
>>> diff --git a/src/xterm.c b/src/xterm.c
>>> index 6a1642ff56e..7391041ea0c 100644
>>> --- a/src/xterm.c
>>> +++ b/src/xterm.c
>>> @@ -23734,6 +23734,7 @@ handle_one_xevent (struct
>>> x_display_info
>>> *dpyinfo,
>>> ptrdiff_t i;
>>> unsigned int old_state;
>>> struct xi_device_t *device, *source;
>>> + bool is_modifier_key;
>>> coding = Qlatin_1;
>>> @@ -24175,17 +24176,7 @@ handle_one_xevent (struct
>>> x_display_info
>>> *dpyinfo,
>>> /* Any "vendor-specific" key is ok. */
>>> || (keysym & (1 << 28))
>>> || (keysym != NoSymbol && nbytes == 0))
>>> - && ! (IsModifierKey (keysym)
>>> - /* The symbols from XK_ISO_Lock
>>> - to XK_ISO_Last_Group_Lock
>>> - don't have real modifiers but
>>> - should be treated similarly to
>>> - Mode_switch by Emacs. */
>>> -#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
>>> - || (XK_ISO_Lock <= keysym
>>> - && keysym <=
>>> XK_ISO_Last_Group_Lock)
>>> -#endif
>>> - ))
>>> + && !is_modifier_key)
>>> {
>>> STORE_KEYSYM_FOR_DEBUG (keysym);
>>> /* make_lispy_event will convert this to a
>>> symbolic
>>> @@ -24204,7 +24195,11 @@ handle_one_xevent (struct
>>> x_display_info
>>> *dpyinfo,
>>> STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
>>> }
>>> - if (nbytes)
>>> + /* Mind that NBYTES can be set even if KEYSYM
>>> + represents a modifier key, but that no
>>> character
>>> + events should be sent in that case. */
>>> +
>>> + if (nbytes && !is_modifier_key)
>>> {
>>> inev.ie.kind =
>>> MULTIBYTE_CHAR_KEYSTROKE_EVENT;
>>> inev.ie.arg = make_unibyte_string
>>> (copy_bufptr,
>>> nbytes);
>
> Please excuse my carelessness, I appear to have ommitted a chunk
> of the
> diff:
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 6a1642ff56e..4b2da066694 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -23734,6 +23734,7 @@ handle_one_xevent (struct x_display_info
> *dpyinfo,
> ptrdiff_t i;
> unsigned int old_state;
> struct xi_device_t *device, *source;
> + bool is_modifier_key;
>
> coding = Qlatin_1;
>
> @@ -24091,6 +24092,18 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> goto xi_done_keysym;
> }
>
> + is_modifier_key = (IsModifierKey (keysym)
> + /* The symbols from
> XK_ISO_Lock
> + to XK_ISO_Last_Group_Lock
> + don't have real modifiers
> but
> + should be treated
> similarly to
> + Mode_switch by Emacs. */
> +#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
> + || (XK_ISO_Lock <= keysym
> + && keysym <=
> XK_ISO_Last_Group_Lock)
> +#endif
> + );
> +
> /* Random non-modifier sorts of keysyms. */
> if (((keysym >= XK_BackSpace && keysym <=
> XK_Escape)
> || keysym == XK_Delete
> @@ -24175,17 +24188,7 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> /* Any "vendor-specific" key is ok. */
> || (keysym & (1 << 28))
> || (keysym != NoSymbol && nbytes == 0))
> - && ! (IsModifierKey (keysym)
> - /* The symbols from XK_ISO_Lock
> - to XK_ISO_Last_Group_Lock
> - don't have real modifiers but
> - should be treated similarly to
> - Mode_switch by Emacs. */
> -#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
> - || (XK_ISO_Lock <= keysym
> - && keysym <=
> XK_ISO_Last_Group_Lock)
> -#endif
> - ))
> + && !is_modifier_key)
> {
> STORE_KEYSYM_FOR_DEBUG (keysym);
> /* make_lispy_event will convert this to a
> symbolic
> @@ -24204,7 +24207,11 @@ handle_one_xevent (struct
> x_display_info *dpyinfo,
> STORE_KEYSYM_FOR_DEBUG (copy_bufptr[i]);
> }
>
> - if (nbytes)
> + /* Mind that NBYTES can be set even if KEYSYM
> + represents a modifier key, but that no
> character
> + events should be sent in that case. */
> +
> + if (nbytes && !is_modifier_key)
> {
> inev.ie.kind =
> MULTIBYTE_CHAR_KEYSTROKE_EVENT;
> inev.ie.arg = make_unibyte_string
> (copy_bufptr, nbytes);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Fri, 25 Aug 2023 02:51:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> Now when I press for instance Space, it doesn't seem to evaluate
> immediately, but it does evaluate when I
> press another dual-function-modified key. So if I press the same
> sequence as below the first message doesn't appear but
> the second one does.
Please pull from the master branch and ascertain if your issues have
been resolved. TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Fri, 25 Aug 2023 08:16:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 65068 <at> debbugs.gnu.org (full text, mbox):
I stashed the patch and pulled from the master branch, then ran
make and make install, then restarted Emacs. Now when I
press Space-CapsLock I get
C-' is undefined
C-<XF86Launch5> is undefined
Po Lu [2023-08-25 Fri 10:49] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> Now when I press for instance Space, it doesn't seem to
>> evaluate
>> immediately, but it does evaluate when I
>> press another dual-function-modified key. So if I press the
>> same
>> sequence as below the first message doesn't appear but
>> the second one does.
>
> Please pull from the master branch and ascertain if your issues
> have
> been resolved. TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Fri, 25 Aug 2023 08:25:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> I stashed the patch and pulled from the master branch, then ran make
> and make install, then restarted Emacs. Now when I
> press Space-CapsLock I get C-' is undefined
> C-<XF86Launch5> is undefined
That's very strange, as the XI keyboard mapping code should now be
equivalent to the core event code. What if you run Emacs with:
src/emacs -q -xrm 'Emacs.disableInputExtension: true'
?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Fri, 25 Aug 2023 08:44:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 65068 <at> debbugs.gnu.org (full text, mbox):
When I press Space-CapsLock there, exactly the same thing happens,
and similar for other combinations. BTW, I'm
currently experimenting with StumpWM and they seem to have a
similar problem. If we can fix this here, maybe we can tell
them what the solution.
Po Lu [2023-08-25 Fri 16:23] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> I stashed the patch and pulled from the master branch, then ran
>> make
>> and make install, then restarted Emacs. Now when I
>> press Space-CapsLock I get C-' is undefined
>> C-<XF86Launch5> is undefined
>
> That's very strange, as the XI keyboard mapping code should now
> be
> equivalent to the core event code. What if you run Emacs with:
>
> src/emacs -q -xrm 'Emacs.disableInputExtension: true'
>
> ?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Sat, 26 Aug 2023 01:40:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 65068 <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> When I press Space-CapsLock there, exactly the same thing happens, and
> similar for other combinations.
How about now?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Sat, 26 Aug 2023 09:45:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 65068 <at> debbugs.gnu.org (full text, mbox):
It works! Thanks so much! Finally I can transition to the new
Emacs version! Say, can you write a high-level summary about what
you did so I can send it to the Stumpwm-people?
Po Lu [2023-08-26 Sat 09:39] wrote:
> Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
>
>> When I press Space-CapsLock there, exactly the same thing
>> happens, and
>> similar for other combinations.
>
> How about now?
Reply sent
to
Po Lu <luangruo <at> yahoo.com>:
You have taken responsibility.
(Sat, 26 Aug 2023 10:03:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Alexander Prähauser <alexander.praehauser <at> gmx.at>:
bug acknowledged by developer.
(Sat, 26 Aug 2023 10:03:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 65068-done <at> debbugs.gnu.org (full text, mbox):
Alexander Prähauser <alexander.praehauser <at> gmx.at> writes:
> It works! Thanks so much! Finally I can transition to the new Emacs
> version! Say, can you write a high-level summary about what you did so
> I can send it to the Stumpwm-people?
The remedy is disabling non-standard behavior imposed by the XFree86 XKB
library, through changing the ControlFallback X library control:
#ifdef XkbLC_ControlFallback
XkbSetXlibControls (dpyinfo->display, XkbLC_ControlFallback, 0);
#endif /* XkbLC_ControlFallback */
Otherwise, XLookupString (and XmbLookupString) endeavor to locate an
ASCII character within a different group if ControlMask is set and the
standard means of keycode mapping produce a function key. In your case,
the keycode array for AC11 still assigned ASCII characters to groups 2
through 4; consequently, group 2 would be consulted in lieu of the key
event's effective group.
I'm closing this bug as fixed; Eli, do you object to installing a
three-line fix incorporating only the code quoted in this e-mail on
emacs-29?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65068; Package
emacs.
(Sat, 26 Aug 2023 10:09:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 65068-done <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 65068-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Sat, 26 Aug 2023 18:01:59 +0800
>
> Eli, do you object to installing a three-line fix incorporating only
> the code quoted in this e-mail on emacs-29?
Please feel free to backport to emacs-29, and thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 23 Sep 2023 11:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 230 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.