I just learned what dead keys really are. The file
/usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose
defines the key combinations necessary to type 'special'characters using the
en_US.UTF-8 locale. 'Why?', you may ask is the dead '~' especially evil? in
a word `rm -r ~/.junk`. If you are in the habbit of typing
<space> and switch to a mapping without dead keys `rm -r ~/.junk' becomes `rm
-r ~ /.junk' which has a whole different meaning.
In preparing this message I did a
`grep "~" /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose' and found there is
also a " : "~" asciitilde" mapping. This is much
better. It could still make working with '~' escapes in ssh rather
confusing, but I see that as a far less likely problem.
In general, now that I understand what ḋead keý means, I donṫ like them.
Thereś got to be a better way!
I have many uses for special characters. They range from transscribing the
Nibelungenlied into electronic text, to building databases representing, for
example, Old Norse words and their inflections, or proto-Germanic and its
relationship to its daughter languages. I also would like to be able to
express mathematical concepts such as ∃,∄, ⋂, ⋃, ⋀, ∩, ∪, ∬. In a
semi-natural way.
And then we hit the obvious problem of which of ⋂ and ∩ is the correct symbol
for the instance in question. Is ∑ the same as Σ? I used `ucm` to pick these
characters out. This is an unusably slow process for any kind of work which
involves extensive use of characters not available in the current key
mapping. The first '∑' is from 'U+2200' and the second 'Σ' is from U+0300.
These appear identical on my SuSE 8.0 box in kmail. I copied these from kmail
to and Emacs buffer and found the first of these characters is not rendered,
and the second is rendered as expected. Hexlifying the buffer holding `∑ Σ'
resulted in the following character codes: e288 9120 cea3. This could be
anoying when it comes to human to human comunication. It is potentially
devistating when it comes to human to computer communication. For example,
imagine a database of words from different languages and data entered by
different users who donṫ fully understand the idosynchracies of UTF encoding.
To the users, everything may appear correct, but what were intended to be
equivalent strings entered by different users may actually be two distinct
representations of the same human readable representation.
I'm sure much of what I'm saying is not news to people on this list. I do
have one proposal for a tool which may help alleviate some of these problems.
It would be nice to have a speciall key sequence to switch quickly between
key mappings (I believe the KDE actually does support this.), and have a
visual representation of the current mapping displayed to the user at will.
It might even be helpfull to be able to browse the available mappings with
the corresponding visual representations displayed to the user before
selecting that particular option.
As it stands, I don't even know if I have a 104 or a 105 keyboard. I don't
know the difference. Things have gotten better regarding selecting keyboards
and such with the KDE. I still find them confusing. A user sould not have
to learn the underlying details of xmodemappings and the
~/.kde/share/config/kxkbrc.
Any thoughts on this?
-- STH
