カーソル&ポインタ操作を効率化する
キーボードの配列を工夫して効率向上を目指している方は結構多いような気がしますが、PCの操作をキーボードだけで完結するのは効率が悪く、ポインタ操作、一般的にはマウス、筆者の場合はタッチパッドによる操作とキーボード操作を行き来することになりますので、全体の入力効率向上を目指すならばポインタ操作も含めた効率改善を考えた方が良いと筆者は考えます。
そして、キーボード単体として見てもカーソル操作には常にもやもやとした非効率感を覚えながら今まで我慢して既存の配列を使い続けてきた、という経過を筆者は辿って来ています。
まず単純に、カーソル操作頻度は結構高いのにキーの配置そのものが端っこに追いやられているため、そもそも手の移動を大きくする必要があり、その分地味に時間が食われていること。
さらには、同じカーソル操作であるにも関わらず、カーソルキーと[Home][End][PgUp][PgDn]キーが離れていたりあるいは[Fn]キーとの同時押しを必要としたりして、ここら辺の往復をするときにはいつも「なんだかなぁ」という感じがするものです。
特に[Fn]キーは多くのキーボードで[Space]キーよりも左側に配置されていることが多く、この場合必ず両手押しが要求されてしまうという欠点があります。
あるいは、ならば、と[Fn]キーが右側にある製品をと入手してみると、確かに右手だけで入力できるようになる点は良いのですが、右下隅の方で2キー同時押しという操作がそもそも案外やり難いことに気付きます。
筆者は[Space]キーの下にタッチパッドを持って来たい派ですので、キーボードの下部周辺に単独で押せるカーソル操作関連キーを集中させるか、もしくは同時押しになることを妥協してホームポジションに手を置いたまま楽に同時押し出来るカーソル操作関連キー配列をすることで大きな効率向上とストレス低減が見込めるのではないかと考えています。
場合によってはアルファベットの並びをアレコレ考えるよりも、カーソル・ポインタ操作周りを先に整理した方が効率向上には効果的なのではないかとさえ思えます。
というわけで、今回はカーソル操作関連キーについて考察していきたいと思います。
え? テンキーパッドをNumLockオフにして使え? うん、それで良い人はそれで良いと思います。
単独カーソルキー割り当て
[変換][カタカナひらがな][(右)Alt][(右)Ctrl]
という、[Space]の右側に並ぶ4つのキーをカーソルキーに割り当てるという大胆な案を実際に少しの間実施していました。
その際、従来のカーソルキーには[Home][End][PgUp][PgDn]を割り当ててみたんですけど、これはどちらをカーソルキーにしてどちらを[Home][End][PgUp][PgDn]の塊にするか悩みました。
が、カーソルキーの方がホームポジションに近い位置にある方が効率的であろう、と考えてカーソルキーを[変換][カタカナひらがな][(右)Alt][(右)Ctrl]へ、従来のカーソルキーを[Home][End][PgUp][PgDn]にしてみたのです。
まぁ……慣れなかったんですけど。
本当にやるならとことん慣れるまで、という気もしたのですが、そこまでメリット無いような気もしたので止めました。
というのも、例えば同時押しキーを[変換]キー辺りに設定できると[IJKL]もしくは[JIO;]を同時押しの方がもしかしたら押し易いかもしれないのです。
右下隅まで手を動かす必要は無くとも、最下段までは手を動かさなければならず、それだったら同時押しでも手を動かさないで済む配置の方がマシかもしれない。
と、現時点では筆者はそう感じました。
単独キーで押せるならより好ましいけど、押し難い単独キーは流石に押し易い同時押しに負けるだろう、という判断です。
同時押しする場合のカーソルキー候補
というわけで、同時押しに使うキーはちょっと置いておいて、同時押し前提で押し易いカーソルキーはドコだ? というのを考察してみたいと思います。
まずは、よくあるパターンが使えないか考えてみます。
当然のことながら、カーソルキー以外のところにカーソルキー同等の働きをするキーを配置しているケースはそれなりにありますので、既存の配置が効果的なのであればわざわざ独自仕様を考えるまでもない、ということでおさらいしてみます。
WASD
キーボード操作でゲームをする人には馴染み深い配置ですので悪くはない選択かもしれません。
筆者は今のところ全く慣れていないので未知数ですが、キーコンフィグに余裕があるなら設定くらいはしてみても良いかも。
ESDX
カーソルキーらしい配置にしたい意味は分かる。が、意外と運指に困る配置。
ホームポジションを崩して[D]キーを人差し指で、[X]キーを親指で打つのが筆者的には合いそう。
だけど、これ必ず何かしらのキーと同時押しのコンフィグになるので、それを考えると……。
例えば[CapsLock]キーを同時押しに使用して、カーソルキーは一個左にずらして[ASWZ]とするならまだ使えるかもしれないが。
FBNP
コマンド操作的なイメージでカーソル操作するのであれば割と連想はしやすい。Forward,Backward,Next,Previousなので。
ただ、これも同時押しキーのことを考えると、カーソル操作キーが左右に分かれてしまっているのが超絶面倒になると思うのですが……。
HJKL
ホームポジションを考えると筆者的にはありえない配置。[H][J]キーがどちらも人差し指になってしまうので非効率も甚だしい。
やるなら一個ずらして[JKL;]にするかな?
いや、筆者の場合はすっと手を置いたときの指の位置は[JIO;]なのでこちらの方が良いかも。
IJKL
WASDの右手版。
細かいことを言うと[I][K]キーがどちらも中指担当になってしまうのだが、馴染みあるカーソルキーの配置に近いというメリットもあるので、そんなに悪くないかも。
有名どころだとだいたいこんな感じでしょうか?
しかし、有名ではあるが、筆者が考えるには若干問題を感じる配置もあるので、ちょっと筆者なりの改善案も出してみます。
ESDF
WASDの1個ズラし。
上記のWASDはタッチタイピング前提で考えると小指薬指中指とちょっと操作しづらい指になってしまいます。
[CapsLock]キーを同時押しするようにコンフィグするのであれば[CapsLock]を小指にしてWASDは指を一つずらして薬指中指人差し指で操作すれば良い、ということになるのかもしれませんが、そうでない場合はホームポジション基準で操作できた方が効率向上すると筆者は考えます。
IJLM
ESDXの右手版。[M]キーは親指で。
テンキーなしキーボードでNumLockが使用できるキーボードでは[8UOK]キーが[8462]でテンキーパッドのカーソルキー配置と同様にはなるが、各行のキーのズレ方を考慮すると、また、ホームポジションとの親和性からも[IJLM]の方が押し易いと思う。
ただし、カーソル移動に右手親指を使ってしまうため、同時押しキーを右手に担当させることが難しくなる。
[Home][End][PgUp][PgDn]割当候補
どうせ同時押しでカーソルキーを定義するのであれば、[Home][End][PgUp][PgDn]キーも含めて候補を考えた方が絶対にお得です。
押し易いところにこれらのキーを固めることが出来ればタッチパッド操作との往復でも手の動きが少なくすみ、また、キー入力とカーソル操作とでの手の移動は不要になります。
これは激しく効率向上に寄与してくれると思うのですが、どうでしょうか?
同時押しキーをどこにするかによっても変わってしまいますが、基本的にはカーソル&[Home][End][PgUp][PgDn]は配置を固めてやった方が操作が散らばらなくて良いかと思います。そもそもこれらが遠かったり離れていたりしていたのが事の発端ですからね。
というわけで、……でもカーソルキーが決まれば候補は自ずと限られてきますね。
同時押しキーの割当候補
元あるキーボードからキーを1つ同時押し用に割り当てることになります。
これ以外にも、筆者はキーボードによってはクリックボタンを1つ割り当てることにしますので、最大2つの既存キーが使えなくなります。
その対処も考えなくてはなりません。
また、キー数の多い日本語配列キーボードではあまり問題になりませんが、キー数の少ないコンパクトキーボードなどではどうするか?
この辺りも含めて考えたいところです。
カーソル操作をするときに同時に[Shift][Ctrl][Alt]を押すことも多々あることを考えるとカーソルキーは右手操作の方が良いかと考えます。
また、同時押しキーがそこで左手になってしまうとカーソル操作に両手が必要になってしまうことと、[Shift][Ctrl][Alt]が絡んだときに左手の操作が混乱しそうなので、同時押しキーも右手操作を前提とした方が良いかと思います。
(もちろん、キー数に余裕があるならば同時押しキーを左手でも右手でも押せるように2キー設定するという手も考えられます。左手操作用カーソルキーとかも設定しても全然良いですしね。)
となると、最有力候補は[Space]キーの右隣のキーでしょうか。日本語キーボードでは[変換]キーですね。
これは親指で押すことになるので、親指を使うつもりだったIJLMはここで親指がバッティングするので候補落ちです。
カーソルキー最終候補
同時押しと[Home][End][PgUp][PgDn]も含めて、押し易いカーソルキーの配置を考えていくと、筆者的には[IJKL]か[JIO;]がカーソルキー割当の有力候補になります。
[IJKL]は元々のカーソルキーの配置に近いのが魅力ですが、上下カーソル移動が同じ中指での操作になるという点ではマイナスです。
慣れることが出来るなら[JIO:]の方が指の分担が完全に分かれてかつ筆者のホームポジションまんまですので、こちらで運用できればベストです。
[Home][End][PgUp][PgDn]をどう周辺に設定するかで結構悩むのですが、単純に上記筆者のホームポジションから1段下げたところにすると覚えやすく、また、ホームポジションからの移動量も最小限で済むので、実際の操作に支障が出なければこれが素直で良いかな?
ただ、話はそこで終わらなくて、各個のキーに何を割り当てるか、考え方によって何パターンかあるので、精査してみる必要があります。
似たような一直線に近い割当を行う有名パターンの[HJKL]ではそれぞれ[←↓↑→]という割当になるそうです。
が、筆者はこのパターンにはやはり納得が行きません。
現在の情報の記載方向というのは上から下、左から右です。←は戻る、↓は進む、↑は戻る、→は進む方向にカーソルを動かすことになるのですが、なんかちぐはぐしてません?
[IJKL]を引っ張って伸ばしたような感覚で割り当てるとするなら筆者は[←↑↓→]の方が的確かと思うのですが。
じゃあ[←↑↓→]で決まりなのかというと、これが最適とは筆者は思っていなくて、例えば情報の戻る量進む量のことを考えると[↑←→↓]の方が理屈に合うんじゃないだろうか? という考えもあったりします。
ただ、これは既存のパターンからかけ離れているので慣れるまでが相当大変そうでして、実際、一時期単独の[変換][カタカナひらがな][(右)Alt][(右)Ctrl]にカーソルを割り当てていたときには[↑←→↓]も試したのですが、違和感バリバリでした。
そして、もう一つ考えられるパターンがあります。
[←→↑↓]です。
一見おかしそうに見えるパターンではありますが、実は指が動き易い人差し指と中指に横方向の移動をまとめている、というのと、上下方向は比較的打ちにくい薬指と小指にはなるのだが筆者的ホームポジションは[JIO;]なので、これの[O]と[;]はキーの配置的にもちょっと上下っぽくなっているので、もしかしたら意外とすんなり飲み込める配置なのかもしれない、という期待があります。
同様にして、そこから1段下げた[MKL/]は同じノリを適用して[Home][End][PgUp][PgDn]にすると、こちらは縦に配置出来なくて横に配置するようになっているキーボードでは大抵この並びですので、意外に馴染み易い配置かも知れません。
というわけで、筆者はとりあえず、[Space]右のキーをレイアウト切替キー(同時押しキー)として使用することにして[JIO:]で[←→↑↓]、[MKL/]で[Home][End][PgUp][PgDn]となるようにキーコンフィグしてみたいと思います。
キーコンフィグの設定方法
過去記事『キーコンフィグで入力環境のレベル底上げを目論む』『Xubuntuのキーボード設定をお勉強』の知見を前提として、なるべく既存の設定を壊さずにコンフィグしたいと思います。
キーボードを打鍵することで発生させることのできるKeycode(InputEventCode)と対応するxmodmapで扱われるKeycodeとを並べて比較してみます。
コンソールでの表示や各所の説明などではどちらもKeycodeと言われていて混乱の元なのですが、ここでは区別のため、前者をEventcode、後者をKeycodeと呼んで区別することにします。
Eventcodeとして設定されていないものはキー入力のしようが無いためここでは除外しまして、Eventcodeとしては存在するがKeycodeの方で設定がされていない、実質完全未使用のコードがいくつかあることが分かります。
筆者の環境ですと、
Eventcode | Keycode |
---|---|
85 KEY_ZENKAKUHANKAKU | keycode 93 = |
95 KEY_KPJPCOMMA | keycode 103 = |
112 KEY_MACRO | keycode 120 = |
141 KEY_SETUP | keycode 149 = |
146 KEY_DELETEFILE | keycode 154 = |
160 KEY_CLOSECD | keycode 168 = |
170 KEY_ISO | keycode 178 = |
175 KEY_MOVE | keycode 183 = |
176 KEY_EDIT | keycode 184 = |
189 KEY_F19 | keycode 197 = |
194 KEY_F24 | keycode 202 = |
209 KEY_BASSBOOST | keycode 217 = |
211 KEY_HP | keycode 219 = |
214 KEY_QUESTION | keycode 222 = |
222 KEY_ALTERASE | keycode 230 = |
240 KEY_UNKNOWN | keycode 248 = |
と、これだけ見つかりました。
逆にxmodmapには定義があるのにEventcode側に定義が無いのでどうにも入力できなさそうなKeycodeもあったりする他、オフセットしている関係でEventcode248の[KEY_MICMUTE]がKeycodeでは範囲である8〜255を超えてしまうためどこに消えた?みたいな感じになっているのですが、これってあれですかね?8オフセットっていう確たる情報を筆者が見つけられたわけではないので、もしかして単純+8オフセットじゃないんですかね?
ちょっと不安になります。
あと、ぱっと見[KEY_ZENKAKUHANKAKU]って凄く日本語配列キーボード左上にあるあの[半角/全角]キーっぽい気がするのにKeycodeに定義が無いというのがとても不思議な印象を受けたのですが、筆者のXubuntuは日本語Remixとか導入していない(ので導入しても変わらないのかも知りません)のですが、[半角/全角]キーは、
Eventcode | Keycode |
---|---|
41 KEY_GRAVE | keycode 49 = Zenkaku_Hankaku Kanji Zenkaku_Hankaku Kanji |
こちらのEventcode,Keycodeで処理されているものと思われます。
あの、英語配列でも同じ位置にくる[`][~]のやつですね。このキー扱いらしいです。どうやら。
あと、[KEY_KPJPCOMMA]も無いの? って一瞬思ってしまいましたが、KPはいわゆるテンキーパッド、JPは日本の、COMMAコンマでして、日本のコンマって何ぞや?状態です。
なお、これとは別のコードで[KEY_KPCOMMA]テンキーパッドのコンマは普通に定義がありますので、うむ、使いどころさんが無いのであろうな……?
Functionキーなんかは[F1]〜[F12]だけでなく[F13]〜[F24]まで定義があるのですが、なぜかxmodmapのKeycodeでは[F19]と[F24]に定義が無く、使い道が無いらしいです。不思議。
とりあえず、日本語を良く使用する筆者としては、ある日突然日本語周りが充実してデフォルト定義が埋められてバッティングとか(しないだろうけど)したら嫌なので[KEY_ZENKAKUHANKAKU][KEY_KPJPCOMMA]は避けて置きまして。
[KEY_UNKNOWN]にしたい気持ちをぐっと抑えて、無難に[KEY_F24]辺りをレイアウト変更キーとして使いましょうか。
[KEY_F24]を押している間だけレイアウト変更するxmodmapの定義は「keycode 202 = Mode_switch」ですが[Shift]押下時いわゆる2つ目をどうしたら良いのかちょっと現時点では良く分かりません。
カーソル操作は範囲指定で[Shift]を使用するので、その[Shift]をこちらで吸ってしまわないように、邪魔しない設定にしたいのですが、未記載で良いのか「NoSymbol」と書いた方が良いのか?
ここいら辺は実際に定義してみて動きを試してみましょうか。
あと、3つ目4つ目も不要そうな気はするのですが、Xubuntuのキーボード設定で検証した感じでは1つ目2つ目と同じ記載を3つ目4つ目にしているので、それに習った方が良いかな?
というわけで、とりあえず、
keycode 202 = Mode_switch NoSymbol Mode_switch NoSymbol
としてみることにします。
Modifier周りは元々設定されていないKeycodeを使用するため変更不要です。
カーソルキー設定は全キーボード共通にするつもり(しないと覚えられない)ですのでxmodmapの当該キーの3つ目4つ目の定義値をカーソル移動に変更しましょう。
筆者が考えた第一候補だとこんな感じ。
keycode 44 = j J Left NoSymbol keycode 31 = i I Right NoSymbol keycode 32 = o O Up NoSymbol keycode 47 = semicolon plus Down NoSymbol keycode 58 = m M Home NoSymbol keycode 45 = k K End NoSymbol keycode 46 = l L Prior NoSymbol keycode 61 = slash question Next NoSymbol
うん、やっぱり[Shift]を吸ってしまわないように偶数番目には「NoSymbol」を書くので正解なような気がするなぁ。
とにかく、これでxmodmapを変更する部分が未使用だったKeycodeに定義を追加したのとレイアウト変更時に使用される3つ目4つ目の定義を変更しただけですので、通常レイアウト部分には一切影響が出ないはずです。
これらを変更した定義ファイルを~/.Xmodmapにでも置いてX起動時にでも読み込ませてあげましょうか。
次にキーボード側の設定変更でレイアウト変更キーとして使いたいキーのキーマップを変更します。
/etc/udev/hwdb.d/61-keyboard-local.hwdbというファイル名で作れって感じのコメントを/usr/lib/udev/hwdb.d/60-keyboard.hwdbの中に発見しましたので、ファイル名を先のとおりにしまして、この中に各キーボードごとにマッピングを変更したい部分を列記していきます。
例えば、これはまだこれから整理する予定なので内容はぐちゃぐちゃなのですが、
evdev:name:Lite-On Tech IBM USB Travel Keyboard with UltraNav*:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70029=leftmeta KEYBOARD_KEY_70035=esc # KEYBOARD_KEY_70088=compose # KEYBOARD_KEY_70045=btn_left KEYBOARD_KEY_7008a=henkan #変換 KEYBOARD_KEY_70088=katakana #カひ KEYBOARD_KEY_700e6=rightalt #R_Alt KEYBOARD_KEY_700e4=rightctrl #R_Ctrl KEYBOARD_KEY_70050=left #← KEYBOARD_KEY_7004f=right #→ KEYBOARD_KEY_70052=up #↑ KEYBOARD_KEY_70051=down #↓ # KEYBOARD_KEY_7008a=left #変換 # KEYBOARD_KEY_70088=down #カひ # KEYBOARD_KEY_700e6=up #R_Alt # KEYBOARD_KEY_700e4=right #R_Ctrl # KEYBOARD_KEY_70050=home #← # KEYBOARD_KEY_7004f=end #→ # KEYBOARD_KEY_70052=pageup #↑ # KEYBOARD_KEY_70051=pagedown #↓ KEYBOARD_KEY_900f6=compose #青スパナ KEYBOARD_KEY_c00ea=rightalt #青スパナの隣 KEYBOARD_KEY_c00e2=rightctrl #単独Mute evdev:name:ELECOM TK-FBP037 series Keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70035=esc evdev:name:Keyboard K380 Keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70035=esc evdev:name:HOLDCHIP USB Gaming Keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70035=esc evdev:name:HTLTEK Gaming keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70035=esc evdev:name:Holtek Semiconductor, Inc. Gaming keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70035=esc evdev:name:Ewin BT5.1 Keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_70035=esc evdev:name:Bluetooth 3.0 Keyboard:dmi:bvn*:bvr*:bd*:svn*:pn* KEYBOARD_KEY_c0223=esc KEYBOARD_KEY_c0224=f1 KEYBOARD_KEY_c018a=f2 KEYBOARD_KEY_c0183=f3 KEYBOARD_KEY_70046=f4 KEYBOARD_KEY_7003d=sysrq KEYBOARD_KEY_c0221=f5 KEYBOARD_KEY_c00b6=f7 KEYBOARD_KEY_c00cd=f8 # KEYBOARD_KEY_c00b5=f9 # KEYBOARD_KEY_70042=leftmeta # KEYBOARD_KEY_c00e2=f10 # KEYBOARD_KEY_70043=compose KEYBOARD_KEY_c00b5=leftmeta KEYBOARD_KEY_c00e2=compose KEYBOARD_KEY_c00ea=f11 KEYBOARD_KEY_70044=yen KEYBOARD_KEY_c00e9=f12 KEYBOARD_KEY_70045=ro KEYBOARD_KEY_700e3=btn_left
これが現在の筆者のキーボード別キーコンフィグの内容です。
現在メインで使用しているIBM USB Travel Keyboard UltraNav付きSK-8845キーボードは一番上の「Lite-On Tech IBM USB Travel Keyboard with UltraNav*」ってやつでして、デバイスとしては1つのキーボードで、
Lite-On Tech IBM USB Travel Keyboard with UltraNav
Lite-On Tech IBM USB Travel Keyboard with UltraNav System Control
Lite-On Tech IBM USB Travel Keyboard with UltraNav Consumer Control
3つのキーボードデバイスが認識され、いわゆる素のキーボード部分と電源コントロールとかスリープとかを制御する部分と音量操作とか再生/停止などメディアコントロール周りの部分に分かれているのですが、まとめた状態でコンフィグした方が楽そうだったので、デバイス名称の共通部分+「*」という形でまとめてコンフィグしています。
ほら、Scancode KEYBOARD_KEY_900f6なんてButtonPageのコードとかc00eaなんてConsumerPageのコードなんかもコンフィグして活用しようとしてる涙ぐましい努力が伺えますね。
なお、c00eaはUsageID EA = Volume Decrement つまり音量下げボタンです。
あと、「Bluetooth 3.0 Keyboard」ってのは過去記事『Bluetooth 3.0 Keyboard』でレビューしたキーボードですが、ファンションキーとメディア関連キーが逆転していて扱い難いのでその辺を中心にコンフィグしていますね。
で、日本語配列キーボードですと大抵[Space]キーの右隣は[変換]キーですので、その場合は対応するキーボードの部分に、
KEYBOARD_KEY_7008a=f24
という行を追記します。
イベントコードで定義されている文言から「KEY_」を除いて小文字化させて書くらしいです。
でもボタンにしたい場合は特に省略とかせずに小文字化だけして書きます。「btn_left」みたいに。
この辺の仕様のちぐはぐさは歴史の経緯上仕方無い部分なんでしょうかね? 凄い混乱の元だと思うのだけど……
インプレッション
とりあえず、動きそのものの印象は悪くないのですが、アプリによっては全く効いてない場合があります。
筆者の環境ではちょっと試しただけでもVisualStudioCodeと、……Kateもダメだぁ!
あとWineで動かしているSakuraEditor、Stirling。もしかしたらWine上で動かすアプリは全滅かもしれません。
しかし、カーソル移動の効率向上策なんてエディターで動作させてこそナンボのものなのに肝心のエディター上で動かないとか致命的です。
これはxmodmap以外の方法を探さないとダメですね。
残念ですが、ここの記事も相当長くなってしまったので、今回は一旦ここで区切ります。
当日追記:
再起動したらVisualStudioCodeでは動くようになった。かと思ったら[Ctrl]とか[Alt]とか絡めてテストしてたら盛大にぶっ壊れて通常の[JIO;MKL/]が打てなくなりました。([変換]キーを押さなくてもカーソル移動になってしまった)
コレが世に聞くfcitxがxmodmapを盛大にぶっ壊す現象か……。なるほどxmodmapでなくxkbでやれと方方で語られている理由の一つが今分かりましたわ。
なおですね、筆者の現状のxmodmapを一部改変してログオン時に読み込ませるようにしたら、なぜかxmodmapの設定が各行2個増えてまして、いや、筆者が変更した行は、
keycode 44 = j J Left
みたいにNoSymbolが消されてしまっただけなのですが、変更していない行が例えば、
keycode 38 = a A a A a A
みたいに定義が2個増えていたんです。
ちょっとこの現象は謎が多いし、盛大にぶっ壊れた状況が発生した以上、やはりxmodmapではない方法を模索した方が良さそうですね。
2024-02-10追記:
実は前からちょっと引っ掛かっていた点があって、キーボードのレイアウトを1種類しか設定していなくてもxmodmapの定義が4つ(2レイアウト分)あったのが不思議だったのですが、もしかしたら後から2個追加されるような処理が走っているのかもしれないと思い、読み込ませる~/.Xmodmapから4つ定義があって1,2番目と3,4番目が同じ内容になっている行は1,2番目だけを残すように変更してみました。
結果、そうしても定義は6個に増えたまま。
どうも、全定義を読み込ませるのは不適なのではないかと感じました。
変更する箇所はそこまで多くは無いので、~/.Xmodmapを読み込ませるのは止めて「xmodmap -e」コマンドで修正する方向で試してみたいと思います。
結果、やはりKateやSakuraEditorなどでカーソルが全く動かないので、やっぱりxmodmap変更という方法は残念ながらボツです。