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 --]
next prev parent 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).