[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs on OS X - configuration package
From: |
Stefan Monnier |
Subject: |
Re: Emacs on OS X - configuration package |
Date: |
Sun, 29 Feb 2004 23:18:02 GMT |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
> I _hope_ these specializations don't become part of the standard
> carbon built. I want emacs to look like emacs regardless of the
> platform.
I wouldn't worry about it. The default bindings will stay as they are, but
maybe some additional Mac-specific bindings could be added and some
Mac-specific options could be added as well.
> the variable mac-command-key-is-meta. Every carbon emacs user I know
> sets this variable to nil, the result of which is to make the apple
> key (aka 'command' or 'cmd' key) map to alt and the option key map to
> meta. It's a little odd the 'alt' key (same as 'option' on apple
I.e. with it set to nil, we can bind A-q to behave like C-x C-c and
Apple-q will then behave as Mac users want without impacting Emacs
old-timers since A-q is currently unbound.
> In X11, the mapping depends on xmodmap in the usual way. All the osx
> emacs users I know who are running an X11 version map apple and option
> to alt and meta, respectively, which gives the same behavior as the
> carbon build when mac-command-key-is-meta is nil.
Well, you now know someone who doesn't: my macosx setup under X11 uses the
default xmodmap (except for the remapping of the funny => key to
Multi_key), which means that Apple maps to Meta. This makes sense since
the key next to it (I guess it's the option key) is labelled Alt on my
PowerBook keyboard.
>>> - When you load a file, a new window opens (Emacs calls this: a frame). (
>>> Closing with Apple-W currently has a few glitches.)
>> This seems completely orthogonal to the OS you're running on.
> It's part of the old macos human-interface guidelines. Personally I
> would _not_ want this behavior in emacs, regardless of platform.
So you agree it's not platform dependent.
Stefan