Subject: Re: keyboard input of arbitrary characters
From: Paul Rohr (email@example.com)
Date: Thu Apr 26 2001 - 20:40:42 CDT
At 10:15 PM 4/26/01 +0200, Mike Nordell wrote:
>I might start this post by saying that I've since got confirmation that this
>is a x86 PC BIOS feature, that we currently in AW (simply because of
>oversight) do not support.
>(I even heard that you can input CTRL-C and NULL using ALT-3 and ALT-257
Shudder. I suppose I'd be willing to accept patches to "fix" this behavior
(ie, enable it on Windows), but boy that's a crufty legacy! If we never did
this, I wouldn't shed a tear.
>But seriously, since this apparently is a BIOS matter we should support it.
>Since the BIOS can't spell Unicode, much less emit it, I think my point of
>leaving this to either the IME or any other application you might have
>running to insert these characters should handle it.
I agree that we shouldn't interfere with any UI choices made at the BIOS
level ... whether we support them or not. If people have been trained that
ALT+keypad stuff generate ASCII or codepage gunk, then we shouldn't violate
that expectation by doing something different there -- not even if we think
our behavior would be "better".
>> Failing that, we should (eventually) do one or both of the following:
>> - extend the symbol dialog to input all Unicode symbols available
>A noble goal, but probably quite a task. One reasonably good implementation
>I've seen of this is Windows 2000 charmap.exe. It also displays a list of
>the Unicode sub-ranges (contained in the font) upon request. Now that's
>good, but I wouldn't say it's a 1.0 feature. More like 2.3.
Agreed. To do this properly would require XP APIs for more poking into font
data than we currently support. For old threads along these lines, see:
This is certainly not a 1.0 feature unless someone gets ambitious. It'll
eventually be nice to have, but I'm even hesitant to write it up as a POW
for fear of distracting a core developer.
>> - create explicit shortcuts for common punctuation characters
>I think this is where we agree on this.
Yeah, we already support Ctrl-Shift-Space to insert a non-breaking space, so
at minimum we should support the usual simple set, even if it does require
us to add NVKs for the keypad:
em | en dash, em | en space,
non-breaking hyphen, optional hyphen,
copyright, registered copyright, trademark,
However, in addition I'm still tempted to pick some prefix which kicks us
into hex-entry mode as described previously. Essentially the idea would be
to swallow four keystrokes after the magic trigger, interpret them as hex,
and do an insertChar() on the result.
For example, if the magic trigger were, say, Ctrl-Esc, then the following
key squence (where commas separate each character typed) would add a bullet:
Ctrl-Esc , 2 , 0 , 2 , 2
Likewise, the following sequence would add an em-dash:
Ctrl-Esc , 2 , 0 , 1 , 4
Or, to show off our hex-ability, here's a right double quote:
Ctrl-Esc , 2 , 0 , 1 , d
Given what I know of Jeff's keybinding mechanism -- ie, it supports more
emacs or vi bindings than I care to admit -- implementing this should be
The three questions become:
1. Is something like this even a good idea?
2. What should the magic trigger be? I happened to pick Ctrl-Esc out of
thin air. Are there any useful precedents we should follow from the UIs of
other Unicode-aware platforms or GUI apps?
3. Who wants to implement it? ;-)
This archive was generated by hypermail 2b25 : Thu Apr 26 2001 - 20:33:12 CDT