From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Hin-Tak Leung via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#50364: 27.2; EDT mode Xmodmap related documentation needs updating Date: Sat, 4 Sep 2021 20:51:37 +0000 (UTC) Message-ID: <71213734.3798271.1630788697800@mail.yahoo.com> References: <880216814.3549587.1630711521093.ref@mail.yahoo.com> <880216814.3549587.1630711521093@mail.yahoo.com> <8335qkyia6.fsf@gnu.org> Reply-To: htl10@users.sourceforge.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3798270_1844354605.1630788697799" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18512"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ca22@cam.ac.uk, 50364@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 04 22:52:28 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mMceK-0004bw-2C for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Sep 2021 22:52:28 +0200 Original-Received: from localhost ([::1]:34856 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMceI-0001v2-QH for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Sep 2021 16:52:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMcdu-0001LD-2u for bug-gnu-emacs@gnu.org; Sat, 04 Sep 2021 16:52:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mMcdt-0004sY-Rw for bug-gnu-emacs@gnu.org; Sat, 04 Sep 2021 16:52:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mMcdt-0003VD-Oe for bug-gnu-emacs@gnu.org; Sat, 04 Sep 2021 16:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Hin-Tak Leung Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Sep 2021 20:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50364 X-GNU-PR-Package: emacs Original-Received: via spool by 50364-submit@debbugs.gnu.org id=B50364.163078870713442 (code B ref 50364); Sat, 04 Sep 2021 20:52:01 +0000 Original-Received: (at 50364) by debbugs.gnu.org; 4 Sep 2021 20:51:47 +0000 Original-Received: from localhost ([127.0.0.1]:48770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mMcdf-0003Uk-Bk for submit@debbugs.gnu.org; Sat, 04 Sep 2021 16:51:47 -0400 Original-Received: from sonic314-20.consmr.mail.ir2.yahoo.com ([77.238.177.146]:34808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mMcdd-0003UU-BV for 50364@debbugs.gnu.org; Sat, 04 Sep 2021 16:51:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1630788699; bh=P337XFVeya7jNGzJAbFDzPDUs48FgsGK//lzfhXikxw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=B3adbpfLrFr7qbIB1qLUDKEs70ZhesqGCP91ubt8kgXr+YEfxhLBZRXDRY4P+dLV6a9KqoNXEglzuK0XjzVRPThSdYvAH8IsfDJObHPStpQ09LTzke0dg0fP8+myILj8gEsWYyZJQkA9U+eYtJoKqzl33A0Jxbltbzd/qZHDjoizDM7pArsYeSkcSF1CArKs+AFxXBpF9oam4fjx93rnI/KfQNoxU8x5eTTPcJZ2EKBI5UcfrPNgAvIpbDhWbFHJLyruDaH9qEiYjZubINwYjmLT1cCMzNKWCKKmU4hU6xYP2A1AM0IM4OiRze9TuIgqV/l/NJ7Qnkum2YwaMSO9vA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1630788699; bh=oWDFa4W1OiminvF2JkR2NqJcQlR7bcjvkcAYNps9ux/=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=BPLzkMmcSb4nt4ISqiP47sK9VUpOdh11ZYWAtuRVu4AmRGJaWYW0xVNfIBGXYJg4tMkVGyQ4Pa5H0broGvOjZgbVL5LFxo4o9nqRoRoMeR+FTR3mFNmQ9A+OYAbn/26L+ZCzfYBz79OPFe9ESo4vaw+EwQVXbk0vIyEof0EIFrtb0BYZw1DDqdZ917WcTXeo/EwfcAbImeOzhGqQXPUaa6P5fe9UkJ31uhwdvH00cv1mobDoDvc6Xfm/rAx30QlJodAGulW2yyd8yyd6iF6wwvk7HKIL30HLTRi+zhgs47H50p81Ev91u87AN0eK6ulicn5a28G5j3H5w64synWsTw== X-YMail-OSG: JQAgbnQVM1luuJyYoixGj3JFMgxP6RIPX5bVDFkFnF4wgKGCBzfieaWyOLIRBVc S3A5Kj0iDCihmJMGHZP_iCK9EwtbUB6gKBdm30UFI18UwdMAuaBLjtsdjTDUg1bP5RXkgL9TeETd 5pVTExD0q3HuEVZKOntn1.Z7zMHbZoozY5PYnIjVHwBrdkLSxuHV4FnCOWlVrMScw_fEg.OI1IOS JESE3j39j_TGiiqefscztqaInwFU1RW4woRPGjExE.ppDHMyNK_mhVFIyMznQyAiusn3UJ3AfgMM fqvEoQQr9udrfLTq9r45PLkYKLx5wzw4Sbe4PXUVhdvuQb9Cl_5yhrrffuuu7g_w.fCxwNPhc.2w en8FlxaFpovFP.oKHuAec8_iTo73Pqq9ezZSznR9W8D6aZy0byOvdO9_r.4UtO6F6Wr8xLzsWCOG Qntk24NO_JYz72Cah_l0XJy.ch6cVTU1wXix2GzqdJtyBsRAQ7OmifMO1Njq8ZY.VR7kZWTOW7.j 8JIeie8og9aA4pKg4ZfUsganPh87W.5ShTzI6em9iJj.1jjw79cJrT6Ipu0HheBU47xnf4G5UMzv hh4MTLt0nwCLsJc5Ngxl_gpLzDycq5O5tOgGq2mMhfhB1p2VQHo725w9S8q8Xn._aW_LybiM4gR3 haBZ.2U9ZConvxrzS.vVJHzPlw344PiJnjGvqnWv_XQvfYbOBQ8KGsQhEGqp4QcJW5qRfWESFL1p kdTaSsEjBRaIHX4FeIn63DehMaSdG4k9d0oLb_4xfT_4zyqm.efwXihsjz6iZje6v4TbvrKDffFH jd8cQItfbPiLrIRBPY2K1iRkF1YtyY7OJz3Twmv7kT X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ir2.yahoo.com with HTTP; Sat, 4 Sep 2021 20:51:39 +0000 In-Reply-To: <8335qkyia6.fsf@gnu.org> X-Mailer: WebService/1.1.18924 YMailNodin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" X-ACL-Warn: , Hin-Tak Leung Xref: news.gmane.io gmane.emacs.bugs:213440 Archived-At: ------=_Part_3798270_1844354605.1630788697799 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaretskii = wrote: > Thanks.=C2=A0 Would you like to write some text that explains how to > achieve this on modern platforms?=C2=A0 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 suppor= t. Thus keyboard layouts are re-applied, whenever user plugs in new external keyboards (for laptops), screensaver/monitor sleeps, or keyboard goes to sl= eep 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 t= o "only" remaps a few keys. The smallest change that is persistent is doing both:=20 Editing /usr/share/X11/xkb/symbols/pc, from 23: key { [ Num_Lock ] }; to 23: key { [ 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 privil= ege, and also needs redoing on package upgrades). There are a few alternative approaches, such as declaring new keyboard layo= uts (scattering a few new files across /usr/share/X11/xkb/ and editing a few ex= isting ones, also require admin privilege) or custom scripts trigged to run on pow= er/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 vint= age, 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! =20 ------=_Part_3798270_1844354605.1630788697799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, 4 September 2021, 07:19:39 BST, Eli Zaret= skii <eliz@gnu.org> wrote:

> Thanks.=C2=A0 Would you like t= o write some text that explains how to
> achieve this on modern platf= orms?=C2=A0 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 whe= n a user logs in
to an X session. This file is ignored for about a decad= e for Gnome now,
and likely KDE, too. The second matter is that even if = a user manually
runs "xmodmap ~/.Xmodmap", gnome-setting-daemo= n (and its KDE
equivalent, kxkb) periodically resets any manually applie= d xmodmap keyboard
mappings.

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

Sin= ce 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 pe= rsistent is doing both:

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

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

The com= bination of these two effectively turns the numerical keypad of the PC keyb= oard
to closer to how the "Apple Aluminium (*)" family of keyb= oards 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 keyboar= d layouts
(scattering a few new files across /usr/share/X11/xkb/ and edi= ting a few existing
ones, also require admin privilege) or custom script= s trigged to run on power/plug
events (details of this functionality see= ms 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 c= ondense and improve the above into a patch, if you are happy to take it...<= br>
Argh, there is also advice about running a script in the background = which
periodically runs "xmodmap ~/.Xmodmap" every 5 or 10 sec= onds!
=20 ------=_Part_3798270_1844354605.1630788697799--