Unicode Events from Keyboard (was: Patch for Mouse-wheel )

Steven Tamm <[email protected]> Wed, 7 Aug 2002 19:00:21 -0700
Newsgroups gmane.emacs.macintosh.devel
Message-ID <[email protected]>
This is getting more complicated the more I look at it.  As this 
convoluted email will show...

> In the interest of keeping this simple model, I am inclined to suggest
> that all key strokes be passed to the Toolbox, and Emacs receives
> whatever is output.

Tried a bunch of different things to see if using 
kEventTextInputUnicodeForKeyEvent for keyboard input would be better.  
This is the Mac OS X way, but being only Unicode seems that it is quite 
geared towards ATSUI and MLTE.  This means that the application needs to 
convert the Unicode to the current text encoding all the time (even if 
using the Roman keyboard).  After working with Java for a few years, I 
like Unicode and think this is probably a good thing.  However, the 
complexity seems to pile up.

1. You need to support the TSM in the application.  Right now it creates 
a TSM Document for each window.  This is probably OK, but it makes the 
keyboard in use window dependent.  So one window would be set for 
Japanese, and the other for U.S.  This can be changed.
2. When you get Unicode, you need to check the source key to see if it 
was a "special" character (like arrows), and if so use that.  Then you 
need to check to see if the meta or control key was down.
3. You need to convert the unicode to the current keyboard encoding.  
Preferably, it would use the current encoding of the buffer, but that 
would require a massive translation table between MULE encoding strings 
and TSM constants.  In any case, I haven't been able to get this to work 
right.
4. kEventTextInputUnicodeForKeyEvent is only available through an 
EventHandler, so keyboard characters need to be posted out of bounds 
using kbd_buffer_store_event

I got something working, but a lot of things are still broken and would 
have to be special cased.  it seems a lot of effort for not that much 
value right now.  When 10.2 is out and the callback based Carbon Event 
Manager can be used, then this is more relevant.

But, if anyone is interested in trying to figure it out, I have some 
code to start with.

> Of course this leaves the problem of M-h and the other M- keys, which
> you prefer not to pass to the Toolbox, and all the C- and C-S- keys,
> which Toshikazu prefers not to pass along to the Toolbox, and M-SPC,
> which should be passed to the Toolbox.  I would not mind working out
> new Lisp variables to treat the disabling of M- and C- keys as special
> cases, rather than choosing one behavior or another as the default
> behavior.

What kind of lisp variables do you think there should be?

-Steven



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf