[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AltGr and Basic Quail Input Method

From: Richard Wordingham
Subject: AltGr and Basic Quail Input Method
Date: Sat, 30 Dec 2017 16:48:46 +0000

It has long irked me that the basic quail input methods, the ones
defined by maps from 'sequences of keystrokes' to strings introduced
by macro quail-define-rules, do not support the 'Alt Gr' modifier key.

I am using GNU/Linux, to be precise Ubuntu 16.04.3 with, I believe, the
Unity desk top. My locale is en_GB.utf8, The general input method
system is fcitx, my default keyboard is the X11 English (US) keyboard,
with the additional 4 system-provided X11 keyboards:

English (UK); Thai - Thai (TIS-820.2538); Khmer (Cambodia); Lao

and two X11 keyboard composed myself:

Thai - Tham Kesmanee and Newa (Newa script).

Unfortunately, under X11 one can only map keysyms to codepoints, not to
user-perceived characters.

I also have some M17N keyboards on my pick list that I run from fcitx.
(I had to patch fcitx to get it to work with AltGr.)

I generally use Emacs 24.4, the version I modified to support stepping
into Indic clusters.

I have dug deeper, and found that there seem to be two obstacles to
using the 'AltGr' modifier key with basic quail input methods. Firstly,
the modifier map I get for my selection of input method and reported by
xmodmap -pm, is:

shift     Shift_L (0x32),  Shift_R (0x3e)
lock      Caps_Lock (0x42)
control   Control_L (0x25),  Control_R (0x69)
mod1      Alt_L (0x40),  Meta_L (0xcd)
mod2      Num_Lock (0x4d)
mod4      Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5      ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

This results in Emacs seeing only shift, control, meta and super
modifiers.  The right Alt key is variously engraved as 'Alt' and 'Alt
Gr', but the associated keysym is ISO_Level3_Shift.  I have not
identified the 'Mode_switch' key on my physical keyboards.

I have found a solution to the first problem.  I launch Emacs from a
terminal emulation, and prior to starting it I issue the command:

xmodmap -e 'keysym Mode_switch = Mode_switch Alt_R'

This then has the effect that Emacs now also sees an alt modifier, which
it registers when I use the AltGr key.

Is there any reason not to change Emacs to treat the ISO_Level3_Shift
if it has rejected the other candidate alt keys?  (Alt_L is rejected
because it is bound to the same modifier as Meta_L - the left alt key
is consequently interpreted by Emacs as a 'meta' key.)  Could this
change be effected more simply in the user's start-up script?

On the quail side, the problem seems to be that input keystrokes are
being stored as a string rather than as a vector.  Is there any reason
not to hope that one can convert the quail input method to deal with
full keystrokes rather than just with characters?  A more ambitious
solution would be to use an input method direct from M17N, but I think
that has a high risk of failure.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]