From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sat Mar 17 2007 - 23:04:42 CST
Richard Wordingham wrote:
> For some keyboards, making <any key, delete> a no-op is an impossibility!
I suppose you mean backspace, not delete... (except on Unix and VT keyboards or in most VT terminal emulations, where this left-pointing arrow key or x within a leftpointing diamond, above the Enter key, generates a delete character).
You forget the most common case on most European keyboards:
the <dead key, backspace> is definitely not a no-op, as the dead-key generates no character to the editor, the backspace key deletes the character that was entered before that sequence, but the dead key remains active for the next key pressed after that sequence.
So pressing:
<a, circumflex dead key, backspace, e>
Does not generate "ae" in the editor, but "ê" (e with circumflex).
Also:
<a, circumflex deadkey, e, backspace, o>
generates "ao", not "aô" because backspace deletes the last generated "ê" (single precomposed character) but also clears the deadkey state so that the "o" is generated without the circumflex.
Some keyboard maps also need to use dead keys before another character, to allow entering extra characters which are not decomposable, but that would be otherwise not mappable in the keymap. If you press backspace after this sequence, it will delete this single character, but will not restore the dead key state.
In fact editors do not manage themselves the dead key state, which remains hidden in the keyboard driver. Some badly written software will trap the dead keys and interpret it at the keycode level, to generate other characters, but will then forbid users to enter the extra characters that are needed for their language. On my extended keyboard, for example, I can type some rare Latin characters, like "ɑ" (Latin alpha), by pressing a special extension deadkey
For example, I have used <AltGr>+* to extend the standard French keyboard to support Latin letters found in some African languages and that normally don't need other diacritics before the normal letter "a". Dead keys are the only way to do that in a keymap where other <AltGr> positions are used for more common non-ASCII letters (that may have their own diacritics requiring normal dead keys: for example <AltGr>+a generates "æ" which may have an acute accent which I can type by pressing the <AltGr>+& deadkey before).
If I had made a keyboard map using the decomposed combining diacritics approach (without dead keys), it would have been impossible to enter "æ" as a single character in the editor, without special composition rules implemented in the editor itself (so this would not have been compatible with most application input forms that use standard Windows common controls).
However, if the editor supports such special handling (like the <Alt+x> key to replace the sequence of hexadecimal digits before the cursor by the Unicode character with that hexadecimal code point), the <Alt+x>,<Bakspace> will definitely not be a no-op, as it will delete the converted character, but will not restore the hexadecimal digits, without extreme complication in the editor (like keeping a trace of previous keystrokes and the associated history of modifications they generated in the editor). In fact <Alt+x> here is not an input character, but an unmapped key which is used as an editor function.
But if the editor makes such internal mapping, it will bypass the normal keymap, which may have its own own of this key, to allow entering some other character (for this reason, editors should not bind editor functions to <AltGr>+x or <Alt+Cltr>+x keys (optionally with Shift), and user keymaps should not bind characters or input dead key states to <Alt+x> (or <Alt+Shift+x>...)
--- Side note: Unfortunately, some softwares make such function bindings to keys that should be reserved to keyboard mappings. I've seen some very bad softwares binding an accelerator function to <Ctrl+Alt+E> without making the distinction between left and right Alt, so that there's no more way to enter <AltGr+E> for typing the Euro symbol... What is worse is that this function mapping had system-wide scope, and was trapped in an utility running in the notication area icon, and it trapped the key in every application, even if that utility did not have input focus. Such application design is typical of some US programmer that don't have or need AltGr on their keyboard... Unfortunately, this running tool was needed to support a removable USB device, and the system-wide function was not modifiable and could not be disabled (this accelerator was just there to allow ejecting the device), so I had to uninstall the driver, and that device was unusable... (On my Acer keyboard which also has an extra Euro symbol key between the up and left cursor arrow keys, this key is hardcoded and behaves exactly as if I had pressed AltGr+E and the keyboard driver can't make the difference, so the device tool thinks I have pressed its system-wide accelerator, and the system ejects the device, which is not what I wanted to do). What this demonstrates is that applications should be tested for usability with some knowledge about international keyboards and what they can do and must not do to work correctly with these keyboards... Philippe.
This archive was generated by hypermail 2.1.5 : Sat Mar 17 2007 - 23:07:27 CST