[Openmcl-devel] support for International keyboards

[Gary Byers]

I vote for all of the above.  Er, below.  Or at least a large subset
of the conventions that you describe.  People have different needs and
expectations, and I think that it should ideally be possible and
simple for a user to select some option that comes closest to meeting
them all.

(I wouldn't want to have to convince someone else that "command as meta,
disable menu key equivalents" is somehow the right thing, but Apple's
X11 offers that as an option and it's possible to get used to it, and
I could imagine using that convention - personally - in the IDE.  I
could as easily imagine that someone else believes that that leads
to street crime or is unthinkably unMac-like.)

If we agree that we should support several conventions and let the
user select whatever convention best matches their needs/habits,
there's still a question of what the out-of-the-box default should be.
I can more or less convince myself that it's better to not enable any
meta modifiers (other than Escape) by default, and let anyone who
expects to use Option or CMD or ... as a meta modifier find the
preference pane that lets them set that.

One last idea (that might or might not be doable and might or might
not be worth adding to this possibly crowded proposed preferences
pane):  Many Mac keyboards have multiple option and command keys
(and/or may have keys with labels like "AltGr" that might act as
"option" or "command" modifiers.  Maybe.)  A keyboard-related
NSEvent has a "modifierFlags" attribute whose value is a bitmask;
the low 16 bits are device-dependent, while the upper 16 bits
are portably defined.  Printing the value of the variable
"modifiers" in the function NS-EVENT-TO-KEY-EVENT seems to show
that the device-dependent bits for "right-option-a" and "left-option-a"
key events on my US keyboard are different, though both events have
the #$NSAlternateKeyMask bit set.  For some users, it might work
best to to ignore the #$NSAlternateKeyMask and say "the device-dependent
bit associated with the left option key should be treated as a Meta
modifier and the other option key should produce cooked self-inserting
characters."

That wouldn't necessarily be any more of a perfect solution than 
any other, but (assuming that it's implementable) it might work
well for some people.  The same could be said for many other
strategies, but different strategies would likely work best for
different people.


On Mon, 6 Apr 2009, Jeremy Jones wrote:

> The Clozure CL IDE doesn't work well with international keyboards
> (e.g. http://trac.clozure.com/openmcl/ticket/182).  We believe that
> most of these problems are caused by the way CCL processes the option
> key.  Currently, the option key is used as the meta modifier for
> editor commands.  Making the option key work like it does in most Mac
> applications should fix most of these problems with international
> keyboards.  The question then becomes, how should we indicate meta for
> editor commands?  Below are some various options for dealing with
> this.  Let us know which you would prefer:
>
> 1.  Keep the option key as meta except when it conflicts with commonly
> used keystrokes for each locale.
>
> This would require getting a list of common option key sequences
> necessary for each locale.  It also means that the subsumed editor
> commands will have different, or no keystroke equivalents.
>
> 2.  Never use the option key for anything but it's intended use on the Mac.
>
> This has the advantage of implementation simplicity.  However, in this
> case how should meta be indicated?
>
> 2a.  Meta is indicated by typing escape first.
>
> This is simple, and is the default for some types of Emacs.
>
> 2b.  Meta is indicated by the command key.
>
> This raises the question of what to do with conflicting menu-key equivalents.
>
> 2b1.  Make none of the menus have command key equivalents.
>
> 2b2.  Give the user the choice of what the various command/key
> combinations do.  Some could be menu equivalents, and some could be
> bound to editor commands.
>
> This is flexible, but it might be confusing and difficult to manage.
>
>
> 2a is the simplest, complete solution.  2b1 is also simple and
> complete.  We could certainly make user preferences for some of these
> options.  Are there any other ideas?  Which choices would people
> prefer?
>
> Thanks,
>
> Jeremy
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>