Re: Carbon.

Aidan Kehoe wrote: > > It’s not practical though, since for most keys option + key generates a > distinct key versus the key on its own in the standard Mac maps. > (Things like œ ˙ é ® þ ¥ for q w e r t z on the German layout.) And > there’s no good way to draw a distinction between option + 4, which > generates € and is necessary for the user, and option + f, which > generates ƒ and really isn’t. > > The Aquamacs people approach this in a very ad-hoc way, with per-language > tables--see > http://google.com/codesearch?hl=en&lr=&q=file%3Aemulate-mac-keybo... > > I suppose though a rule of thumb would be ‘if the character generated > with option both: > > 1. Differs from the character generated without option and > 2. Is either ASCII (because our users are programmers) or is necessary to > write the currently active language > > then option + char-without-option should generate char-with-option; > otherwise option + char-without-option should generate > M-char-without-option.’ The information on the characters necessary to > write a language is available in the language-specific Quail tables, > though it is incomplete right now. > > This is horrible. I've just starting using Emacs.app for OS X. And, it works the way I would expect. You can set whichever key that you want to for Meta (default alt/option) and still use the Apple/Command key (recognized as super). And, it allows you to do Mule without the problems of Aquamacs.

Instead of Carbon, it uses Cocoa/OpenStep/NextStep/whatever you want to call it. Maybe this would be a better basis for the XEmacs port to OS X. I know, patches welcome... But, if anyone is interested, it can be found at http://emacs-app.sourceforge.net/ Right now, everything seems to work except 2-finger scrolling.