bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

I have these entries in ~/.Xmodmap:

keysym Super_L = slash
keysym Menu = backslash

In my latest build from master (details below), the Super_L assignment
is ignored and Emacs does not react at all to pressing the Super_L key
(the Menu assignment is still recognized).  According to git bisect the
following commit introduced this behavior change:

15910e5da34a084fe01e0fd96ecf394cb1030e25 is the first bad commit
commit 15910e5da34a084fe01e0fd96ecf394cb1030e25
Author: Po Lu <luangruo@yahoo.com>
Date:   Sun Feb 20 10:03:28 2022 +0800

    Ignore modifier keys early when handling X key press events

    * src/xterm.c (handle_one_xevent): Ignore modifier keys earlier
    without going through the usual key lookup.
    (x_delete_terminal): Free recorded modifier map.
    (x_find_modifier_meanings): Record modifier map.

    * src/xterm.h (struct x_display_info): New field `modmap'.


In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-03-06 built on strobelfs2
Repository revision: 98d2dc6522114e4044077801f11a3ed8de9c1147
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Linux From Scratch r11.0-165

Configured using:
 'configure --with-xinput2 --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> In my latest build from master (details below), the Super_L assignment
> is ignored and Emacs does not react at all to pressing the Super_L key
> (the Menu assignment is still recognized). 
[...]

> In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
>  of 2022-03-06 built on strobelfs2
> Repository revision: 98d2dc6522114e4044077801f11a3ed8de9c1147
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
> System Description: Linux From Scratch r11.0-165

I'm unable to reproduce this on Debian/bullseye.  Our conf looks pretty
similar:

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.16.0)
 of 2022-03-06 built on xo
Repository revision: 98d2dc6522114e4044077801f11a3ed8de9c1147
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Debian GNU/Linux bookworm/sid


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

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Mon, 07 Mar 2022 16:24:06 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> In my latest build from master (details below), the Super_L assignment
>> is ignored and Emacs does not react at all to pressing the Super_L key
>> (the Menu assignment is still recognized).
> [...]
>
>> In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.31,
>> cairo version 1.17.4)
>>  of 2022-03-06 built on strobelfs2
>> Repository revision: 98d2dc6522114e4044077801f11a3ed8de9c1147
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
>> System Description: Linux From Scratch r11.0-165
>
> I'm unable to reproduce this on Debian/bullseye.  Our conf looks pretty
> similar:
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31,
> cairo version 1.16.0)
>  of 2022-03-06 built on xo
> Repository revision: 98d2dc6522114e4044077801f11a3ed8de9c1147
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
> System Description: Debian GNU/Linux bookworm/sid

Is your build without --with-pgtk?  I don't have the issue on my
--with-pgtk build.  But without --with-pgtk it's completely reproducible
for me (both with and without --with-native-compilation).  How do you
evaluate the keysym assignments?  In my ~/.bash_profile I have `xmodmap
~/.Xmodmap'.

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> Is your build without --with-pgtk?

No.

> I don't have the issue on my
> --with-pgtk build.  But without --with-pgtk it's completely reproducible
> for me (both with and without --with-native-compilation).  How do you
> evaluate the keysym assignments?  In my ~/.bash_profile I have `xmodmap
> ~/.Xmodmap'.

Me, too.

Perhaps it's a window manager issue?  I use Gnome Shell.

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

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Mon, 07 Mar 2022 16:59:48 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Is your build without --with-pgtk?
>
> No.
>
>> I don't have the issue on my
>> --with-pgtk build.  But without --with-pgtk it's completely reproducible
>> for me (both with and without --with-native-compilation).  How do you
>> evaluate the keysym assignments?  In my ~/.bash_profile I have `xmodmap
>> ~/.Xmodmap'.
>
> Me, too.
>
> Perhaps it's a window manager issue?  I use Gnome Shell.

I'm using xfwm4.  But with the same window manager I don't have the
problem with emacs-28.

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> I have these entries in ~/.Xmodmap:
>
> keysym Super_L = slash
> keysym Menu = backslash
>
> In my latest build from master (details below), the Super_L assignment
> is ignored and Emacs does not react at all to pressing the Super_L key
> (the Menu assignment is still recognized).  According to git bisect the
> following commit introduced this behavior change:

Thanks, that's very odd.  Do GTK programs also ignore this mapping?

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I have these entries in ~/.Xmodmap:
>>
>> keysym Super_L = slash
>> keysym Menu = backslash
>>
>> In my latest build from master (details below), the Super_L assignment
>> is ignored and Emacs does not react at all to pressing the Super_L key
>> (the Menu assignment is still recognized).  According to git bisect the
>> following commit introduced this behavior change:
>
> Thanks, that's very odd.  Do GTK programs also ignore this mapping?

If that is so, you probably have a stray modifier bound to Super_L
(perhaps Mod4?)

In that case, you should also add:

  remove Super_L = Mod4

Or something of the sorts to your .Xmodmap.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 08:39:59 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> I have these entries in ~/.Xmodmap:
>>>
>>> keysym Super_L = slash
>>> keysym Menu = backslash
>>>
>>> In my latest build from master (details below), the Super_L assignment
>>> is ignored and Emacs does not react at all to pressing the Super_L key
>>> (the Menu assignment is still recognized).  According to git bisect the
>>> following commit introduced this behavior change:
>>
>> Thanks, that's very odd.  Do GTK programs also ignore this mapping?

AFAIK Xfce4 uses Gtk3, and e.g. xfce4-terminal and thunar (file manager)
recognize my Super_L mapping to `/'.  LibreOffice does too.  The only
other program I use that ignores Super_L is Firefox, but it has since
long before this Emacs problem started (with your commit 15910e5d
according to git bisect); I've search the web about this Firefox issue
but haven't found anything.

> If that is so, you probably have a stray modifier bound to Super_L
> (perhaps Mod4?)
>
> In that case, you should also add:
>
>   remove Super_L = Mod4
>
> Or something of the sorts to your .Xmodmap.

The only uncommented lines im my .Xmodmap file are these:

remove Lock      = Caps_Lock
keysym Caps_Lock = Control_L
add    Control   = Control_L
keysym Super_L = slash
keysym Menu = backslash

Of these, Emacs fails to recognize only the Super_L mapping, since the
above-mentioned commit.  (As an experiment I added `remove Super_L =
Mod4' before the Super_L = slash mapping, logged out and back in, but
the result was that none of the .Xmodmap mappings were recognized, not
just in Emacs but also e.g. in xfce4-terminal.  So I removed that line
to restore the status quo ante.)

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> AFAIK Xfce4 uses Gtk3, and e.g. xfce4-terminal and thunar (file manager)
> recognize my Super_L mapping to `/'.  LibreOffice does too.  The only
> other program I use that ignores Super_L is Firefox, but it has since
> long before this Emacs problem started (with your commit 15910e5d
> according to git bisect); I've search the web about this Firefox issue
> but haven't found anything.

Interesting, but please see below.

> Of these, Emacs fails to recognize only the Super_L mapping, since the
> above-mentioned commit.  (As an experiment I added `remove Super_L =
> Mod4' before the Super_L = slash mapping, logged out and back in, but
> the result was that none of the .Xmodmap mappings were recognized, not
> just in Emacs but also e.g. in xfce4-terminal.  So I removed that line
> to restore the status quo ante.)

Can you show the output of running just `xmodmap' without any arguments?
I suspect that some modifier is mapped to Super_L, alongside slash.

That is incorrect, so Emacs and Firefox are within their rights to
ignore such a mapping.

Thanks.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 18:10:45 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> AFAIK Xfce4 uses Gtk3, and e.g. xfce4-terminal and thunar (file manager)
>> recognize my Super_L mapping to `/'.  LibreOffice does too.  The only
>> other program I use that ignores Super_L is Firefox, but it has since
>> long before this Emacs problem started (with your commit 15910e5d
>> according to git bisect); I've search the web about this Firefox issue
>> but haven't found anything.
>
> Interesting, but please see below.
>
>> Of these, Emacs fails to recognize only the Super_L mapping, since the
>> above-mentioned commit.  (As an experiment I added `remove Super_L =
>> Mod4' before the Super_L = slash mapping, logged out and back in, but
>> the result was that none of the .Xmodmap mappings were recognized, not
>> just in Emacs but also e.g. in xfce4-terminal.  So I removed that line
>> to restore the status quo ante.)
>
> Can you show the output of running just `xmodmap' without any arguments?

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        slash (0x85),  Super_R (0x86),  slash (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

> I suspect that some modifier is mapped to Super_L, alongside slash.

Is the above output consistent with the five mappings in my .Xmodmap
file?

> That is incorrect, so Emacs and Firefox are within their rights to
> ignore such a mapping.

If so, how do I get the mapping of Super_L to slash back (at least in
Emacs)?

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock
> control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
> mod1        Alt_L (0x40),  Meta_L (0xcd)
> mod2        Num_Lock (0x4d)
> mod3
> mod4        slash (0x85),  Super_R (0x86),  slash (0xce),  Hyper_L (0xcf)
> mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
>
>> I suspect that some modifier is mapped to Super_L, alongside slash.
>
> Is the above output consistent with the five mappings in my .Xmodmap
> file?

No: mod4 is both slash

>> That is incorrect, so Emacs and Firefox are within their rights to
>> ignore such a mapping.
>
> If so, how do I get the mapping of Super_L to slash back (at least in
> Emacs)?

Try adding this to your ~/.Xmodmap and evaluating it as well:

  remove mod4 = Super_R
  remove mod4 = Hyper_L

Also add this if you're sure you don't want the actual slash to be
treated as mod4:

  remove mod4 = slash

And see if that resolves the problem.  Also, please tell if that makes
Firefox recognize the mapping as well.

Thanks.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 18:28:43 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> shift       Shift_L (0x32),  Shift_R (0x3e)
>> lock
>> control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
>> mod1        Alt_L (0x40),  Meta_L (0xcd)
>> mod2        Num_Lock (0x4d)
>> mod3
>> mod4        slash (0x85),  Super_R (0x86),  slash (0xce),  Hyper_L (0xcf)
>> mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
>>
>>> I suspect that some modifier is mapped to Super_L, alongside slash.
>>
>> Is the above output consistent with the five mappings in my .Xmodmap
>> file?
>
> No: mod4 is both slash

You mean forward slash and backslash?  I.e. mod4 subsumes the Super_L
and Menu keysyms?

>>> That is incorrect, so Emacs and Firefox are within their rights to
>>> ignore such a mapping.
>>
>> If so, how do I get the mapping of Super_L to slash back (at least in
>> Emacs)?
>
> Try adding this to your ~/.Xmodmap and evaluating it as well:
>
>   remove mod4 = Super_R
>   remove mod4 = Hyper_L
>
> Also add this if you're sure you don't want the actual slash to be
> treated as mod4:
>
>   remove mod4 = slash
>
> And see if that resolves the problem.  Also, please tell if that makes
> Firefox recognize the mapping as well.

I tried with all three remove mappings and also with just the first two,
but in both cases nothing changed, i.e., typing Super_L (the Windows key
on my keyboard) still produced nothing in emacs-29 (non-pgtk build).
Same in Firefox.  FWIW evaluating `xmodmap .Xmodmap' gives this output
(both with the lines you suggested adding and without them):

xmodmap:  .Xmodmap:16:  bad keysym in remove modifier list 'Caps_Lock', no corresponding keycodes
xmodmap:  .Xmodmap:18:  bad keysym target keysym 'Caps_Lock', no corresponding keycodes
xmodmap:  .Xmodmap:49:  bad keysym target keysym 'Super_L', no corresponding keycodes
xmodmap:  .Xmodmap:52:  bad keysym target keysym 'Menu', no corresponding keycodes
xmodmap:  4 errors encountered, aborting.

Nevertheless, only the Super_L mapping fails in emacs-29 (and Firefox).

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> You mean forward slash and backslash?  I.e. mod4 subsumes the Super_L
> and Menu keysyms?

No, just forward slash.

> I tried with all three remove mappings and also with just the first two,
> but in both cases nothing changed, i.e., typing Super_L (the Windows key
> on my keyboard) still produced nothing in emacs-29 (non-pgtk build).
> Same in Firefox.  FWIW evaluating `xmodmap .Xmodmap' gives this output
> (both with the lines you suggested adding and without them):
>
> xmodmap:  .Xmodmap:16:  bad keysym in remove modifier list 'Caps_Lock', no corresponding keycodes
> xmodmap:  .Xmodmap:18:  bad keysym target keysym 'Caps_Lock', no corresponding keycodes
> xmodmap:  .Xmodmap:49:  bad keysym target keysym 'Super_L', no corresponding keycodes
> xmodmap:  .Xmodmap:52:  bad keysym target keysym 'Menu', no corresponding keycodes
> xmodmap:  4 errors encountered, aborting.
>
> Nevertheless, only the Super_L mapping fails in emacs-29 (and Firefox).

Thanks, then please run GDB, and add a breakpoint like this:

  (gdb) break xterm.c:12731

It should then print something along the lines of

  Breakpoint N at 0x505332: file xterm.c, line 12731.

At this point, say:

  (gdb) condition N rec->map->modmap[xev->detail] != 0
  (gdb) commands
  Type commands for breakpoint(s) 3, one per line.
  End with a line saying just "end".
  >p rec->map->modmap[xev->detail]
  >c
  >end

where N is the number of the breakpoint that was printed above, then run
Emacs like this:

  (gdb) run -q -xrm 'Emacs.useXIM: false'

Press the left super key, and show the output.  Thanks.

If GDB complains about values being optimized out, try building without
optimizations.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 19:13:10 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> You mean forward slash and backslash?  I.e. mod4 subsumes the Super_L
>> and Menu keysyms?
>
> No, just forward slash.
>
>> I tried with all three remove mappings and also with just the first two,
>> but in both cases nothing changed, i.e., typing Super_L (the Windows key
>> on my keyboard) still produced nothing in emacs-29 (non-pgtk build).
>> Same in Firefox.  FWIW evaluating `xmodmap .Xmodmap' gives this output
>> (both with the lines you suggested adding and without them):
>>
>> xmodmap: .Xmodmap:16: bad keysym in remove modifier list 'Caps_Lock', no
>> corresponding keycodes
>> xmodmap: .Xmodmap:18: bad keysym target keysym 'Caps_Lock', no corresponding
>> keycodes
>> xmodmap: .Xmodmap:49: bad keysym target keysym 'Super_L', no corresponding
>> keycodes
>> xmodmap:  .Xmodmap:52:  bad keysym target keysym 'Menu', no corresponding keycodes
>> xmodmap:  4 errors encountered, aborting.
>>
>> Nevertheless, only the Super_L mapping fails in emacs-29 (and Firefox).
>
> Thanks, then please run GDB, and add a breakpoint like this:
>
>   (gdb) break xterm.c:12731
>
> It should then print something along the lines of
>
>   Breakpoint N at 0x505332: file xterm.c, line 12731.
>
> At this point, say:
>
>   (gdb) condition N rec->map->modmap[xev->detail] != 0
>   (gdb) commands
>   Type commands for breakpoint(s) 3, one per line.
>   End with a line saying just "end".
>   >p rec->map->modmap[xev->detail]
>   >c
>   >end
>
> where N is the number of the breakpoint that was printed above, then run
> Emacs like this:
>
>   (gdb) run -q -xrm 'Emacs.useXIM: false'
>
> Press the left super key, and show the output.  Thanks.

My xterm.c is not quite up to date, so I adjusted the breakpoint:

(gdb) break xterm.c:12547
Breakpoint 3 at 0x55b4c9: file /home/steve/src/emacs/emacs-master/src/xterm.c, line 12547.
(gdb) condition 3 rec->map->modmap[xev->detail] != 0
(gdb) commands
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>p rec->map->modmap[xev->detail]
>c
>end
(gdb) run -q -xrm 'Emacs.useXIM: false'
Starting program: /home/steve/build/emacs-master/src/emacs -q -xrm 'Emacs.useXIM: false'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffea505640 (LWP 10837)]
[New Thread 0x7fffe9af7640 (LWP 10838)]
[New Thread 0x7fffe8f9a640 (LWP 10839)]
[New Thread 0x7fffdbfff640 (LWP 10840)]
[Thread 0x7fffdbfff640 (LWP 10840) exited]
[New Thread 0x7fffdbfff640 (LWP 10841)]
[New Thread 0x7fffdb66f640 (LWP 10842)]
[Thread 0x7fffdbfff640 (LWP 10841) exited]
[Thread 0x7fffdb66f640 (LWP 10842) exited]
[New Thread 0x7fffdb66f640 (LWP 10843)]
[New Thread 0x7fffdbfff640 (LWP 10844)]
[Thread 0x7fffdb66f640 (LWP 10843) exited]
[Thread 0x7fffdbfff640 (LWP 10844) exited]

Thread 1 "emacs" hit Breakpoint 3, handle_one_xevent (dpyinfo=dpyinfo@entry=0xd586e0, event=event@entry=0x7fffffffd410, finish=finish@entry=0xaac980 <current_finish>, hold_quit=0x7fffffffd660) at /home/steve/src/emacs/emacs-master/src/xterm.c:12549
warning: Source file is more recent than executable.
12549			  if (rec->map->modmap && rec->map->modmap[xev->detail])
$1 = 64 '@'
[Thread 0x7fffe8f9a640 (LWP 10839) exited]

The GDB session is still running; do you want any further output?

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Thread 1 "emacs" hit Breakpoint 3, handle_one_xevent
> (dpyinfo=dpyinfo@entry=0xd586e0, event=event@entry=0x7fffffffd410,
> finish=finish@entry=0xaac980 <current_finish>,
> hold_quit=0x7fffffffd660) at
> /home/steve/src/emacs/emacs-master/src/xterm.c:12549
> warning: Source file is more recent than executable.
> 12549			  if (rec->map->modmap && rec->map->modmap[xev->detail])
> $1 = 64 '@'
> [Thread 0x7fffe8f9a640 (LWP 10839) exited]
>
> The GDB session is still running; do you want any further output?
>
> Steve Berman

That indicates the super key is still Mod4.  Can you show the output of
running `xmodmap' after evaluating the lines I sent earlier?

Thanks.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 19:51:55 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Thread 1 "emacs" hit Breakpoint 3, handle_one_xevent
>> (dpyinfo=dpyinfo@entry=0xd586e0, event=event@entry=0x7fffffffd410,
>> finish=finish@entry=0xaac980 <current_finish>,
>> hold_quit=0x7fffffffd660) at
>> /home/steve/src/emacs/emacs-master/src/xterm.c:12549
>> warning: Source file is more recent than executable.
>> 12549			  if (rec->map->modmap && rec->map->modmap[xev->detail])
>> $1 = 64 '@'
>> [Thread 0x7fffe8f9a640 (LWP 10839) exited]
>>
>> The GDB session is still running; do you want any further output?
>>
>> Steve Berman
>
> That indicates the super key is still Mod4.  Can you show the output of
> running `xmodmap' after evaluating the lines I sent earlier?

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        slash (0x85),  Super_R (0x86),  slash (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

I ran `xmodmap .Xmodmap' with those lines added and then ran just
xmodmap, getting the above ouput.  This is identical to the output of
xmodmap I sent previously, without the added lines from you.  Do the
added lines need to be in a particular order with respect to the
existing lines?  Currently my .Xmodmap has these uncommented lines, in
the order listed:

remove Lock      = Caps_Lock
keysym Caps_Lock = Control_L
add    Control   = Control_L
remove mod4 = Super_R
remove mod4 = Hyper_L
remove mod4 = slash
keysym Super_L = slash
keysym Menu = backslash

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
>
> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock
> control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
> mod1        Alt_L (0x40),  Meta_L (0xcd)
> mod2        Num_Lock (0x4d)
> mod3
> mod4        slash (0x85),  Super_R (0x86),  slash (0xce),  Hyper_L (0xcf)
> mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
>
> I ran `xmodmap .Xmodmap' with those lines added and then ran just
> xmodmap, getting the above ouput.  This is identical to the output of
> xmodmap I sent previously, without the added lines from you.  Do the
> added lines need to be in a particular order with respect to the
> existing lines?  Currently my .Xmodmap has these uncommented lines, in
> the order listed:
>
> remove Lock      = Caps_Lock
> keysym Caps_Lock = Control_L
> add    Control   = Control_L
> remove mod4 = Super_R
> remove mod4 = Hyper_L
> remove mod4 = slash
> keysym Super_L = slash
> keysym Menu = backslash
>
> Steve Berman

What happens if you run this command after loading the .Xmodmap file?

  $ xmodmap -e 'remove mod4 = Super_R' -e 'remove mod4 = Hyper_L' -e \
  'remove mod4 = slash'

Thanks.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 20:59:39 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
>>
>> shift       Shift_L (0x32),  Shift_R (0x3e)
>> lock
>> control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
>> mod1        Alt_L (0x40),  Meta_L (0xcd)
>> mod2        Num_Lock (0x4d)
>> mod3
>> mod4        slash (0x85),  Super_R (0x86),  slash (0xce),  Hyper_L (0xcf)
>> mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
>>
>> I ran `xmodmap .Xmodmap' with those lines added and then ran just
>> xmodmap, getting the above ouput.  This is identical to the output of
>> xmodmap I sent previously, without the added lines from you.  Do the
>> added lines need to be in a particular order with respect to the
>> existing lines?  Currently my .Xmodmap has these uncommented lines, in
>> the order listed:
>>
>> remove Lock      = Caps_Lock
>> keysym Caps_Lock = Control_L
>> add    Control   = Control_L
>> remove mod4 = Super_R
>> remove mod4 = Hyper_L
>> remove mod4 = slash
>> keysym Super_L = slash
>> keysym Menu = backslash
>>
>> Steve Berman
>
> What happens if you run this command after loading the .Xmodmap file?
>
>   $ xmodmap -e 'remove mod4 = Super_R' -e 'remove mod4 = Hyper_L' -e \
>   'remove mod4 = slash'

With that Super_L (the Windows key) is again recognized as `/' in
emacs-29 and also in Firefox.  Why does this work but having the
mappings in .Xmodmap doesn't?  (I also tried putting those three
mappings after the five mappings I've been using for years in .Xmodmap,
but it makes no difference.)

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> With that Super_L (the Windows key) is again recognized as `/' in
> emacs-29 and also in Firefox.

That confirms it's not really a bug in Emacs.  But I will look for a
better solution to this problem (the commit which introduced this
problem was originally put in to satisfy buggy input methods which act
on modifier keys, but don't filter them out).  Thanks.

> Why does this work but having the mappings in .Xmodmap doesn't?  (I
> also tried putting those three mappings after the five mappings I've
> been using for years in .Xmodmap, but it makes no difference.)

As for that, I have no idea.

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Andreas Schwab]

On Mär 08 2022, Stephen Berman wrote:

> Why does this work but having the mappings in .Xmodmap doesn't?

As you have written yourself the mappings were never applied:

> xmodmap:  4 errors encountered, aborting.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 21:35:21 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> With that Super_L (the Windows key) is again recognized as `/' in
>> emacs-29 and also in Firefox.
>
> That confirms it's not really a bug in Emacs.  But I will look for a
> better solution to this problem (the commit which introduced this
> problem was originally put in to satisfy buggy input methods which act
> on modifier keys, but don't filter them out).  Thanks.

Thank you, I appreciate it.

>> Why does this work but having the mappings in .Xmodmap doesn't?  (I
>> also tried putting those three mappings after the five mappings I've
>> been using for years in .Xmodmap, but it makes no difference.)
>
> As for that, I have no idea.

Well, at least you've given me a workaround for now.  Thanks.

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Stephen Berman]

On Tue, 08 Mar 2022 14:52:09 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Mär 08 2022, Stephen Berman wrote:
>
>> Why does this work but having the mappings in .Xmodmap doesn't?
>
> As you have written yourself the mappings were never applied:
>
>> xmodmap:  4 errors encountered, aborting.

That's what it looks like.  But then why do the mappings of Caps_Lock
and Menu work (and Super_L did until the commit in question)?  I've been
using that .Xmodmap for years and never had a problem with the mappings
in Emacs till that commit (but only with the Super_L in Firefox).  If
the mappings haven't been applied, why do the keys work as if they did?
I haven't set these keys in any other way that I'm aware of.

Steve Berman

bug#54289: 29.0.50; Emacs ignores xmodmap Super_L assignment

[Andreas Schwab]

On Mär 08 2022, Stephen Berman wrote:

> That's what it looks like.  But then why do the mappings of Caps_Lock
> and Menu work (and Super_L did until the commit in question)?

X keymap settings are not idempotent.  For example, once you have
removed the keycode mapping for the Caps_Lock keysym it cannot be
resolved any more.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."