unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Hin-Tak Leung via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ca22@cam.ac.uk, 50364@debbugs.gnu.org
Subject: bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating
Date: Sat, 4 Sep 2021 20:51:37 +0000 (UTC)	[thread overview]
Message-ID: <71213734.3798271.1630788697800@mail.yahoo.com> (raw)
In-Reply-To: <8335qkyia6.fsf@gnu.org>

[-- 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 --]

  reply	other threads:[~2021-09-04 20:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <880216814.3549587.1630711521093.ref@mail.yahoo.com>
2021-09-03 23:25 ` 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
2021-09-04  6:19   ` Eli Zaretskii
2021-09-04 20:51     ` Hin-Tak Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-09-28 13:15       ` Stefan Kangas
2022-08-23  1:01       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-19 14:42     ` Hin-Tak Leung via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-19 16:09       ` Eli Zaretskii
2022-08-22 20:09       ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=71213734.3798271.1630788697800@mail.yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=50364@debbugs.gnu.org \
    --cc=ca22@cam.ac.uk \
    --cc=eliz@gnu.org \
    --cc=htl10@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).