bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Hin-Tak Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Been fighting with EDT mode configuration for a few weeks. 

The fundamental problem is that all the Xmodmap related instruction in
    https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/edt.texi#n418
and the entire section from about
    https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/edt.texi#n325
to
    https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/edt.texi#n530
is significantly outdated, by about a whole decade.

Modern Linux - and also Sun Workstations which have Gnome as desktop - supports
plug-and-play keyboards and mouses with X Keyboard Extension, and would periodically
reset any manually applied xmodmap settings; and also since about Gnome 3.6
(around 2010), ignores .Xmodmap .

The proper way of remapping the Num_Lock key to EDT's GOLD key usage
is via a custom keyboard layout with X Keyboard Extension. Failing that,
the Apple family of xkb keyboard models, "Apple laptop", and "Apple Aluminium (*)", 
apple_laptop/applealu_ansi/applealu_iso/applealu_jis , have a definition
for the Clear key at that key location.

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Eli Zaretskii]

> Date: Fri, 3 Sep 2021 23:25:21 +0000 (UTC)
> Cc: Charles Aylmer <ca22@cam.ac.uk>
> From:  Hin-Tak Leung via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Been fighting with EDT mode configuration for a few weeks. 
> 
> The fundamental problem is that all the Xmodmap related instruction in
>     https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/edt.texi#n418
> and the entire section from about
>     https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/edt.texi#n325
> to
>     https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/edt.texi#n530
> is significantly outdated, by about a whole decade.
> 
> Modern Linux - and also Sun Workstations which have Gnome as desktop - supports
> plug-and-play keyboards and mouses with X Keyboard Extension, and would periodically
> reset any manually applied xmodmap settings; and also since about Gnome 3.6
> (around 2010), ignores .Xmodmap .
> 
> The proper way of remapping the Num_Lock key to EDT's GOLD key usage
> is via a custom keyboard layout with X Keyboard Extension. Failing that,
> the Apple family of xkb keyboard models, "Apple laptop", and "Apple Aluminium (*)", 
> apple_laptop/applealu_ansi/applealu_iso/applealu_jis , have a definition
> for the Clear key at that key location.

Thanks.  Would you like to write some text that explains how to
achieve this on modern platforms?  We could then update or augment
what the manual says as appropriate.

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Hin-Tak Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

 On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks.  Would you like to write some text that explains how to
> achieve this on modern platforms?  We could then update or augment
> what the manual says as appropriate.

Yes, I could do that, when I figure out a neat way of doing it.

The current EDT documentation is misleading/out-dated in two aspects:
it gives the impression that ~/.Xmodmap is auto-applied when a user logs in
to an X session. This file is ignored for about a decade for Gnome now,
and likely KDE, too. The second matter is that even if a user manually
runs "xmodmap ~/.Xmodmap", gnome-setting-daemon (and its KDE
equivalent, kxkb) periodically resets any manually applied xmodmap keyboard
mappings.

As far as I understand it, this is driven by two modern linux usages: plug-and-play
keyboards and power management, and desktop-wide international input support.
Thus keyboard layouts are re-applied, whenever user plugs in new external
keyboards (for laptops), screensaver/monitor sleeps, or keyboard goes to sleep
and wake up. Keyboard layouts are also reset when a user explicitly choose
to input non-ascii characters via switching the desktop input methods.

Since modern Xorg can auto-detect unusual keyboards and already bundles
190 models and 100 layouts (on my system), it seems to be quite difficult to
"only" remaps a few keys.

The smallest change that is persistent is doing both: 

Editing /usr/share/X11/xkb/symbols/pc, from
23: key <NMLK> { [ Num_Lock ] };
to
23: key <NMLK> { [ Clear ] };

and append to "gsettings get org.gnome.desktop.input-sources xkb-options" (retrieving the current xkb options)
with 'numpad:mac' using "gsettings set org.gnome.desktop.input-sources xkb-options" (setting it).

The combination of these two effectively turns the numerical keypad of the PC keyboard
to closer to how the "Apple Aluminium (*)" family of keyboards behave.

This approach suffers from editing a system file (and requires admin privilege, and
also needs redoing on package upgrades).

There are a few alternative approaches, such as declaring new keyboard layouts
(scattering a few new files across /usr/share/X11/xkb/ and editing a few existing
ones, also require admin privilege) or custom scripts trigged to run on power/plug
events (details of this functionality seems to have changed over the years, and
flaky). So I haven't found a satisfactory answer that is simple, persistent,
user-config-only without root privilege, applicable to different Linux vintage, yet.

I can condense and improve the above into a patch, if you are happy to take it...

Argh, there is also advice about running a script in the background which
periodically runs "xmodmap ~/.Xmodmap" every 5 or 10 seconds!  

[-- Attachment #2: Type: text/html, Size: 3086 bytes --]

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Stefan Kangas]

Hin-Tak Leung <htl10@users.sourceforge.net> writes:

> I can condense and improve the above into a patch, if you are happy to take it...

It seems like you got no reply here, but to clarify, we would indeed be
happy to take such a patch.  Thank you for working on this.

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Hin-Tak Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

 

On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks.  Would you like to write some text that explains how to
> achieve this on modern platforms?  We could then update or augment
> what the manual says as appropriate.

I should say that I intend to come back to this, and submit a patch/diff to the documentation when I find the time to do so. Hopefully before Christmas...  

[-- Attachment #2: Type: text/html, Size: 505 bytes --]

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Eli Zaretskii]

> Date: Tue, 19 Oct 2021 14:42:09 +0000 (UTC)
> From: Hin-Tak Leung <htl10@users.sourceforge.net>
> Cc: 50364@debbugs.gnu.org, ca22@cam.ac.uk
> 
> On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Thanks.  Would you like to write some text that explains how to
> > achieve this on modern platforms?  We could then update or augment
> > what the manual says as appropriate.
> 
> I should say that I intend to come back to this, and submit a patch/diff to the documentation when I find the
> time to do so. Hopefully before Christmas... 

Thanks in advance.

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

[Lars Ingebrigtsen]

Hin-Tak Leung <htl10@users.sourceforge.net> writes:

>
> On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Thanks.  Would you like to write some text that explains how to
>> achieve this on modern platforms?  We could then update or augment
>> what the manual says as appropriate.
>
> I should say that I intend to come back to this, and submit a patch/diff to the
> documentation when I find the time to do so. Hopefully before Christmas... 

This was more than half a year ago -- did you make any progress here?

bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating

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

Hin-Tak Leung <htl10@users.sourceforge.net> writes:

> Yes, I could do that, when I figure out a neat way of doing it.
>
> The current EDT documentation is misleading/out-dated in two aspects:
> it gives the impression that ~/.Xmodmap is auto-applied when a user logs in
> to an X session. This file is ignored for about a decade for Gnome now,
> and likely KDE, too. The second matter is that even if a user manually
> runs "xmodmap ~/.Xmodmap", gnome-setting-daemon (and its KDE
> equivalent, kxkb) periodically resets any manually applied xmodmap keyboard
> mappings.
>
> As far as I understand it, this is driven by two modern linux usages: plug-and-play
> keyboards and power management, and desktop-wide international input support.
> Thus keyboard layouts are re-applied, whenever user plugs in new external
> keyboards (for laptops), screensaver/monitor sleeps, or keyboard goes to sleep
> and wake up. Keyboard layouts are also reset when a user explicitly choose
> to input non-ascii characters via switching the desktop input methods.
>
> Since modern Xorg can auto-detect unusual keyboards and already bundles
> 190 models and 100 layouts (on my system), it seems to be quite difficult to
> "only" remaps a few keys.
>
> The smallest change that is persistent is doing both: 
>
> Editing /usr/share/X11/xkb/symbols/pc, from
> 23: key <NMLK> { [ Num_Lock ] };
> to
> 23: key <NMLK> { [ Clear ] };
>
> and append to "gsettings get org.gnome.desktop.input-sources xkb-options" (retrieving the current xkb options)
> with 'numpad:mac' using "gsettings set org.gnome.desktop.input-sources xkb-options" (setting it).
>
> The combination of these two effectively turns the numerical keypad of the PC keyboard
> to closer to how the "Apple Aluminium (*)" family of keyboards behave.
>
> This approach suffers from editing a system file (and requires admin privilege, and
> also needs redoing on package upgrades).
>
> There are a few alternative approaches, such as declaring new keyboard layouts
> (scattering a few new files across /usr/share/X11/xkb/ and editing a few existing
> ones, also require admin privilege) or custom scripts trigged to run on power/plug
> events (details of this functionality seems to have changed over the years, and
> flaky). So I haven't found a satisfactory answer that is simple, persistent,
> user-config-only without root privilege, applicable to different Linux vintage, yet.
>
> I can condense and improve the above into a patch, if you are happy to take it...
>
> Argh, there is also advice about running a script in the background which
> periodically runs "xmodmap ~/.Xmodmap" every 5 or 10 seconds! 

Please keep the previous method documented.  I don't use plug-and-play
keyboards (indeed PS/2 is not even safe to hotplug), and in addition to
that, Emacs runs on ancient X servers all the way back to the original
X11R6 sample server.