On Monday 23 September 2002 14:57, Mike Fabian wrote:
"Steven T. Hatton" <hattons@speakeasy.net> writes:
On Friday 20 September 2002 21:14, Mike Fabian wrote: I do use the compose for Á,Ó,Ú,Đ,Þ.Ö, etc. When I looked through the /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose file I saw that many of the characters require dead keys. That's what got me talking about the dead '~'.
You can edit the /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose file to make the characters you need available using <Multi_key> rather than dead keys. For example, if
<dead_diaeresis> <o> : "ö" odiaeresis
is contained in /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose, it does not mean that you can't add other entries for other key combinations to write the same character. For example,
<Multi_key> <o> <colon> : "ö" odiaeresis
coexists without problems in /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose.
I.e. if characters you need frequently have only entries which require dead keys in /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose, you can add other keycombinations using <Multi_key> to type the same characters if you like.
If you do that, keep a backup copy of your edited Compose file in order not to loose it when you update your system.
I understand that you are giving me the best 'reasonable' solution available. I appreciate the help, so please don't misunderstand what I'm about to say. [NB: all of the following can be summarized by saying: 'there are too many variables, and there is not enough orthogonality in the design.' I'm not trying to say I am unwilling to attempt the modifications suggested. I'm merely giving feedback so the process might be improved. I'm basing this on my own experience.] For a person who lives and breaths special character keyboard mappings, solutions such as "just go hack the /somewhere/over/the/rainbow/X11/keyboardprimaryalterativemodepapping.cfg" file and add '<toto>=<stupid little dog>', but remember the activation order is important..." might seem like an obvious solution. For a person whose primary interest is the morphology of reconstructed, hypothetical proto languages, such instructions can usually be followed. A problem comes about when Dr. Esoteric applies a patch a year later and his keyboard stops producing a Ç when he types <Multi_key> <C> <comma>. Or he tries to explain how to do this to a person on a mailing list, and his instructions result in that person messing up the configuration his graduate student provided for him before she switched to computer science.
I guess I don't need the dead key combos for much, right now. What would be nice is some kind of escape sequence which would allow me to enter <super-escape-key-combo>[unicode hex representation] and out comes the exact character I'm looking for.
That is possible with IIIMF. IIIMF is a new input mechanism, developed by Hideki Hiura and Miyashita Hisashi.
I could not yet make it work on SuSE Linux, but I hope that it will work soon.
IIIMF uses an extended Compose file which has several sections and one can switch between the sections using special key combinations. There are key combinations which switch to a Unicode hex input mode:
<Multi_key> <u> <h> : SWITCH_STATE_TO "[ Unicode Hex ]" Ctrl<T> <u> <h> : SWITCH_STATE_TO "[ Unicode Hex ]"
I would prefer a ~./compose/custom-1.conf ~./compose/custom-2.conf, etc. type of functionality. The idea of making modifications to system files is, as a general rule, bad. Even system wide modifications should be handled by things such as /etc/profile.local, /etc/sysconfig/some-component.conf, etc. I've spent too many hours trying to figure out why my keyboard stopped working after applying a patch. It becomes even more of a problem when some guy on the XEmacs beta list, whose display name is "If you knew my name, you'd probably hunt me down and kill me", tells you t fix it by modifying your ~/.Xmodmap, when the problem is really in the ~/.kde/share/config/kxkbrc.
Another option might be to hijack the number pad for custom key mappings. Have some way of putting the keyboard input mechanism into a special mode where the number pad keystrokes result in
You can also use xmodmap to map the number pad keys to anything you like.
For example, if you create a ~/.Xmodmap file containing
keysym KP_Enter = EuroSign keysym KP_Add = 0x01006f22
and load it with
xmodmap ~/.Xmodmap
you can enter the EuroSign by typing KP_Enter and the Unicode character U+6f22 (漢) by typing KP_Add.
You can have several such files, ~/.Xmodmap-1 ~/.Xmodmap-2, ... and switch between them using 'xmodmap ~/.Xmodmap-1' etc. ...
These kinds of solutions can be confusing because it's hard to determine if they are affecting a change in the specific shell, or in the current X session. And you also have to remember how you had configured this, and how to make it work. If you do it every day, it's not hard. If you spend a few hours setting this up the way you want it, and don't use it for several months, you may end up repeating all the learning you did in the first place.
In general a more user friendly means of learning the the compose keystrokes would be nice.
Currently you can only read /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose.
One thing I don't really understand is why not simply have some kind of escape key for dead keys. Or is that what [M ~] really is?
You can achieve the same result with other keys instead of dead keys in /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose, if that is what you mean. You can use e.g. <Multi_key> or Ctrl<T> like in the above examples.
IMHO a system file such as /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose should be standard across all installations. When someone says she is using: Geeko Cogwheel -> Preferences -> Peripherals -> Keyboard -> Enable keyboard layouts=t Keyboard Model = Generic 104-key PC Primary Layout = [en-US Flag] U.S. English w/ ISO9995-3 Primary Variant = basic a person on the other side of the world should be able to set his system to the same values, and achieve the same results.