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 <dead_tilde> <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 "<dead_tilde> <dead_tilde> : "~" 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