Emacs on OS X - configuration package

Emacs on OS X - configuration package

[David Reitter]

Hi,

In November 2003, I asked a couple of questions regarding how to get 
Emacs to integrate into Mac OS X, for example to display only one frame 
per buffer. Quite a few people got back to me about that, thanks.

I have compiled a series of packages to work with Andrew Choi's port and 
decided to release it, even though it is far from perfect.  Mac users 
can find my configuration package at

http://www.reitter-it-media.de/software/osx_emacs.html

I am using this with a recent built from source; I have a link (and a 
mirror) of binaries from mindlube on the page for your convenience.

Among the things changed by the package are:

- OS X standard keyboard shortcuts: Apple-S saves a file, Apple-Q for 
quit, Apple-C/X/V for clipboard operations, Apple-F to find a string - 
and many more

- Emacs has a normal menu.

- When you load a file, a new window opens (Emacs calls this: a frame). (
Closing with Apple-W currently has a few glitches.)

- Clipboard operations interoperate with other Mac apps. However, if you 
mark a chunk of text, it will be automatically copied into the clipboard. (
How can I get rid of this?)

- Recent Files are available from the File menu.

- Mouse Wheel works

- Emacs remains extensible, so you can use special syntax coloring 
setups or enjoy embedded CVS support, a HTML markup menu and the like.

I would like to improve this with more tweaks and welcome patches.

Dave 

Re: Emacs on OS X - configuration package

[Arjan Bos]

David Reitter wrote:

> Hi,
> 
> In November 2003, I asked a couple of questions regarding how to get 
> Emacs to integrate into Mac OS X, for example to display only one frame 
> per buffer. Quite a few people got back to me about that, thanks.
> 
> I have compiled a series of packages to work with Andrew Choi's port and 
> decided to release it, even though it is far from perfect.  Mac users 
> can find my configuration package at
> 
> http://www.reitter-it-media.de/software/osx_emacs.html
> 
> I am using this with a recent built from source; I have a link (and a 
> mirror) of binaries from mindlube on the page for your convenience.
> 

Mmm, I can see that this is a wonderful effort. However, I'm not 
entirely sure whether I like it or not. The point is that I work in a 
multi OS environment, and on every environment (KDE, NT4, OS X 10.3) the 
   graphical user interface guidelines are different. Emacs however 
always lets me type C-x s or C-xC-f or, to close a window, C-x 5 o. So I 
do not have to reprogram my fingers between <ctrl>-F4 or Command-W to 
close a window.

As a matter of fact, when using NT4, I find myself pressing windows-s to 
save a file.

So for me, the current configuration of emacs is ideal.


And you're right in stating that the one true editor is better 
configurable and cheaper to obtain than BBEdit, so your effort might put 
more people on their way to enlightment ;-)

By the way, did you know that Andrew's patches are in the emacs cvs 
repository?


Arjan
-- 
--
If you really want to contact me, then replace the "I see you" text by 
its three letter accronym, ICU.

Fabricate Diem PVNC, Motto of the Night Watch -- Terry Pratchett

Re: Emacs on OS X - configuration package

[Stefan Monnier]

> I am using this with a recent built from source; I have a link (and a 
> mirror) of binaries from mindlube on the page for your convenience.

I assume you're working with the CVS version of Emacs, so it would be good
to send such messages to emacs-devel@gnu.org and to try and get some of
your changes installed in Emacs-CVS.

> - OS X standard keyboard shortcuts: Apple-S saves a file, Apple-Q for
> quit, Apple-C/X/V for clipboard operations, Apple-F to find a string -
> and many more

What is `Apple' mapped to in Emacs terms?  If those bindings override some
of the default bindings, then maybe it would be better to get your behavior
by hacking on cua-mode.

> - Emacs has a normal menu.

Good.

> - 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.

> - Mouse Wheel works

Didn't it already work before?


        Stefan

Re: Emacs on OS X - configuration package

[Tim McNamara]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> - OS X standard keyboard shortcuts: Apple-S saves a file, Apple-Q
>> for quit, Apple-C/X/V for clipboard operations, Apple-F to find a
>> string - and many more
>
> What is `Apple' mapped to in Emacs terms?  If those bindings
> override some of the default bindings, then maybe it would be better
> to get your behavior by hacking on cua-mode.

I've looked briefly at this package and since I use Emacs under
Apple's X11 interface not Aqua, much of it would have to be altered to
be useful for me.  However, as an 18 year veteran of Mac OS I can
address a few things.

The Apple key, a.k.a. the Command (Cmd) key, serves as Meta
inconsistently.  If (setq mac-command-key-is-meta nil) is set, then
these keybindings would not override any Emacs Meta keybindings, I
would think; that setq makes Alt function as Meta.  IME however, this
is *highly* inconsistent, and may function differently in Emacs built
for Apple's Mac OS X Aqua interface vs. the OS X X11 interface (which
BTW runs rootless by default and is interleaved with Aqua application
windows).  However, if Cmd = Meta, then there are conflicts in the
keybindings- M-q and Cmd-q, for example.

Cmd-Q is the universal keybinding for quitting an application under
Mac OS.  It doesn't work with Andrew Choi's patches- you have to use
C-x C-c to quit Emacs.  Cmd-Q would in this instance be the same as
C-x C-c; I presume this is an additional keymapping rather than an
override.  C-w would become Cmd-x in this scheme, and C-y would become
Cmd-v; M-w would be Cmd-c.

>> - Emacs has a normal menu.
>
> Good.

This probably means "normal" in Mac terms, which puts the menu bar at
the top of the screen, separate from the window (frame) of the
application.  Although Emacs built with Andrew's patches for Mac OS X
Aqua does have "normal" Mac menus.

>> - 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.

Most Mac applications open files in a new window (frame) with one
buffer per frame.  You can bring any window forward by clicking on it.
The Emacs approach to this takes quite a bit of getting used to for
Mac users.

>> - Mouse Wheel works
>
> Didn't it already work before?

Inconsistent again.  I find that the mouse wheel worked in some Aqua
builds but does not work at all in builds for Apple's X11 interface.
It does function at button 2 if clicked, but provides no scrolling.
No settings in .emacs will make the mouse wheel work IME.

Pressing the mouse wheel and scrolling will do a C-y of the most
recent item in the kill ring, though.

Re: Emacs on OS X - configuration package

[Stefan Monnier]

> I've looked briefly at this package and since I use Emacs under
> Apple's X11 interface not Aqua, much of it would have to be altered to
> be useful for me.

For the X11 build of Emacs, I think we want to stay as "plain Emacs" as
possible: people who want a Macish feel should use the Carbon version.

> The Apple key, a.k.a. the Command (Cmd) key, serves as Meta
> inconsistently.

What do you mean by inconsistently?

> If (setq mac-command-key-is-meta nil) is set, then
> these keybindings would not override any Emacs Meta keybindings, I
> would think; that setq makes Alt function as Meta.

My question was: what will it appear as.  From what you say it will appear
as Meta by default and can be changed to appear as ... what ... Alt?

> IME however, this is *highly* inconsistent, and may function differently
> in Emacs built for Apple's Mac OS X Aqua interface vs. the OS X X11

Inconsistent with what?  Under X11, the Apple key appears as Meta, so it
seems the defaults are consistent.

>>> - Emacs has a normal menu.
>> Good.
> This probably means "normal" in Mac terms, which puts the menu bar at
> the top of the screen, separate from the window (frame) of the
> application.  Although Emacs built with Andrew's patches for Mac OS X
> Aqua does have "normal" Mac menus.

I believe he was talking about the Carbon version and was hence referring
to the Emacs *menu* (not menubar) which until now was fairly non-standard
(e.g. no `exit' entry IIRC).

> Most Mac applications open files in a new window (frame) with one
> buffer per frame.

Hmmm AFAIK most Mac applications don't have the notion of buffer-vs-window,
and this equally applies to Windows and X11.  Emacs does it differently,
but the difference is not specific to Mac.

> You can bring any window forward by clicking on it.  The Emacs approach to
> this takes quite a bit of getting used to for Mac users.

Again, non-specific to Mac.  I'm not arguing the feature is bad (after all,
I've been using such a one-frame-per-buffer scheme for years and it took
a good bit of effort), just that it should be available to non-Mac users
as well.

>>> - Mouse Wheel works
>> Didn't it already work before?
> Inconsistent again.  I find that the mouse wheel worked in some Aqua
> builds but does not work at all in builds for Apple's X11 interface.

Which Emacs build are you referring to?  Have you tried Emacs-CVS recently?
I use my mouse wheel all the time with no problem in Emacs/X11/Mac.


        Stefan

Re: Emacs on OS X - configuration package

[Tim McNamara]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I've looked briefly at this package and since I use Emacs under
>> Apple's X11 interface not Aqua, much of it would have to be altered
>> to be useful for me.
>
> For the X11 build of Emacs, I think we want to stay as "plain Emacs"
> as possible: people who want a Macish feel should use the Carbon
> version.

I use the X11 version because I prefer the way it "feels" to the Aqua
versions, and also because it seems faster under X11 than it did under
Aqua.  However, it would be good for people to have the option to
"Macify" the X11 build if they want- I guess.  But I agree that the
default for X11 should be the default POSIX-type standard unless the
user chooses to change it.

>> The Apple key, a.k.a. the Command (Cmd) key, serves as Meta
>> inconsistently.
>
> What do you mean by inconsistently?

<snip>

>> IME however, this is *highly* inconsistent, and may function
>> differently in Emacs built for Apple's Mac OS X Aqua interface
>> vs. the OS X X11
>
> Inconsistent with what?  Under X11, the Apple key appears as Meta,
> so it seems the defaults are consistent.

Actually, under OS X 10.3.2, built from CVS using Andrew Choi's
patches (./configure --without-aqua --with-x) neither the Cmd key nor
the Alt key function as Meta.  Only the Esc key is available as Meta.
I *think* the problem is aactually in Apple's X11; Cmd or Alt worked
as Meta under XDarwin and OroborOSX in OS X 10.1.5.  In fact, Cmd-w
results in trying to exit Emacs and getting dialog boxes about saving
buffers and newsrc-dribble.

>>>> - Mouse Wheel works
>>>
>>> Didn't it already work before?
>>
>> Inconsistent again.  I find that the mouse wheel worked in some
>> Aqua builds but does not work at all in builds for Apple's X11
>> interface.
>
> Which Emacs build are you referring to?  Have you tried Emacs-CVS
> recently?  I use my mouse wheel all the time with no problem in
> Emacs/X11/Mac.

I built from CVS, umm, maybe 8 weeks ago.  Just after I bought OS X
10.3 and the build I had done under 10.1.5 was broken.  I have only
had the mouse wheel work under Aqua builds (and again I think this is
an Apple problem; the scroll wheel doesn't work in other X11 windows
either).

Re: Emacs on OS X - configuration package

[Stefan Monnier]

> Actually, under OS X 10.3.2, built from CVS using Andrew Choi's
> patches (./configure --without-aqua --with-x)

I assume you mean Emacs's CVS repository, but I don' know what patches
you're referring to.

> neither the Cmd key nor the Alt key function as Meta.  Only the Esc key is
> available as Meta.  I *think* the problem is aactually in Apple's X11; Cmd
> or Alt worked as Meta under XDarwin and OroborOSX in OS X 10.1.5.
> In fact, Cmd-w results in trying to exit Emacs and getting dialog boxes
> about saving buffers and newsrc-dribble.

Under X11 with OS X 10.3.2 my Apple key is mapped to Meta by default.
This is completely independent of Emacs, of course, and can simply be
checked with `xev'.  Are you sure your problems aren't due to some
xmodmap fiddling?

> had the mouse wheel work under Aqua builds (and again I think this is
> an Apple problem; the scroll wheel doesn't work in other X11 windows
> either).

My wheel works fine under X11 on OS X 10.3.2, as does the fn+touchpad trick
provided by the `ucontrol' utility.  Maybe I'm just lucky,


        Stefan

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-03-01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> had the mouse wheel work under Aqua builds (and again I think this is
>> an Apple problem; the scroll wheel doesn't work in other X11 windows
>> either).
>
> My wheel works fine under X11 on OS X 10.3.2, as does the fn+touchpad trick
> provided by the `ucontrol' utility.  Maybe I'm just lucky,


The scroll wheel on my Logitech mouse works fine in Apple's X11, in
emacs as well as other contexts.  I can't remember it ever _not_
working.

Re: Emacs on OS X - configuration package

[Tim McNamara]

videoxfer <videoxfer@xfer.tv> writes:

> On 2004-03-01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> had the mouse wheel work under Aqua builds (and again I think this
>>> is an Apple problem; the scroll wheel doesn't work in other X11
>>> windows either).
>>
>> My wheel works fine under X11 on OS X 10.3.2, as does the
>> fn+touchpad trick provided by the `ucontrol' utility.  Maybe I'm
>> just lucky,
>
> The scroll wheel on my Logitech mouse works fine in Apple's X11, in
> emacs as well as other contexts.  I can't remember it ever _not_
> working.

Interesting.  Neither my old Micro$oft optical Intellimouse nor my
Kensington Iridio scroll wheels work with X11 or Emacs, although they
work(ed) with the Aqua interface in 10.1.5 and 10.3.2.  So, as far as
I can tell it's an Apple issue, perhaps something specific to my
computer or to old iMacs in general, and probably OT for this
newsgroup.

Re: Emacs on OS X - configuration package

[Tim McNamara]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Actually, under OS X 10.3.2, built from CVS using Andrew Choi's
>> patches (./configure --without-aqua --with-x)
>
> I assume you mean Emacs's CVS repository, but I don' know what
> patches you're referring to.

Andrew Choi committed patches to Savannah for Emacs to be optionally
built as a Carbon application for Mac OS X quite some time ago, and
was the maintainer of this until November.  Without these patches,
AFAIK, Emacs can't be built for Carbon and the Aqua interface.

>> neither the Cmd key nor the Alt key function as Meta.  Only the Esc
>> key is available as Meta.  I *think* the problem is aactually in
>> Apple's X11; Cmd or Alt worked as Meta under XDarwin and OroborOSX
>> in OS X 10.1.5.  In fact, Cmd-w results in trying to exit Emacs and
>> getting dialog boxes about saving buffers and newsrc-dribble.
>
> Under X11 with OS X 10.3.2 my Apple key is mapped to Meta by
> default.  This is completely independent of Emacs, of course, and
> can simply be checked with `xev'.  Are you sure your problems aren't
> due to some xmodmap fiddling?

I've never touched xmodmap.  It's all vanilla in this regard.

>> had the mouse wheel work under Aqua builds (and again I think this
>> is an Apple problem; the scroll wheel doesn't work in other X11
>> windows either).
>
> My wheel works fine under X11 on OS X 10.3.2, as does the
> fn+touchpad trick provided by the `ucontrol' utility.  Maybe I'm
> just lucky,

Perhaps a hardware issue?  I'm running this on a Rev B iMac.

Re: Emacs on OS X - configuration package

[Stefan Monnier]

> Andrew Choi committed patches to Savannah for Emacs to be optionally
> built as a Carbon application for Mac OS X quite some time ago, and
> was the maintainer of this until November.  Without these patches,
> AFAIK, Emacs can't be built for Carbon and the Aqua interface.

Oh, I get it.  I thought you meant some additional patches on top of the
code that's already in CVS (your `--without-aqua' threw me off even more
since the CVS code does not use the `aqua' word but `carbon' instead).

> Perhaps a hardware issue?  I'm running this on a Rev B iMac.

Maybe bugs in Apple's X11 which make it work correctly with some
keyboards/mouses and not with others.


        Stefan

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-02-29, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I assume you're working with the CVS version of Emacs, so it would be good
> to send such messages to emacs-devel@gnu.org and to try and get some of
> your changes installed in Emacs-CVS.

I _hope_ these specializations don't become part of the standard
carbon built.  I want emacs to look like emacs regardless of the
platform.


> What is `Apple' mapped to in Emacs terms?  

In the carbon build it's either alt or meta, depending on the value of
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
keyboards) isn't mapped to alt.  But for consistency with running
emacs in a Terminal it makes more sense (see below).

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.

When running in a Terminal window, the apple key is used for
application commands, in the usual mac way, and can't be remapped. The
option key can be set to act as meta, at least to some extent, which
is consistent with the other two modes.


>> - Emacs has a normal menu.
>
> Good.

I agree it sounds good, but I don't know what the OP means here.  The
standard carbon build already has a 'normal' menu.



>> - 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.


>> - Mouse Wheel works
>
> Didn't it already work before?

It did.

Re: Emacs on OS X - configuration package

[Stefan Monnier]

> 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

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-02-29, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> - 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.
>
> So you agree it's not platform dependent.

No, I don't agree with that.  The earlier poster is trying to get
emacs to match the Mac HIG, at least in part.  That's what I was
pointing out: it's very consistent with his other platform dependent
mods.  I don't want this particular behavior precisely because it _is_
platform dependent, and I want emacs not to be.

Re: Emacs on OS X - configuration package

[Stefan Monnier]

>>>>> - 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.
[Here you snipped the important part where you said:
 Personally I would not want this behavior in Emacs, regardless of platform.]
>> So you agree it's not platform dependent.
> No, I don't agree with that.

Oh well.  It's not like it matters anyway.  The only point is that it makes
sense to turn it ON or OFF regardless of the platform and that the
implementation is unlikely to depend on OS-specific features.  Maybe some
platforms would like it better one way or another, but the default is
a very minor part of the code, and it is extremely unlikely that it will be
changed from the current behavior anyway.


        Stefan

Re: Emacs on OS X - configuration package

[Piet van Oostrum]

>>>>> videoxfer <videoxfer@xfer.tv> (V) wrote:

V> In the carbon build it's either alt or meta, depending on the value of
V> the variable mac-command-key-is-meta.  Every carbon emacs user I know
V> sets this variable to nil, 

Well, I don't. The main reason is that I would loose the Alt-keyboard
function which gives me acces to non-ASCII characters, like the Euro sign
and accented characters. Yes, I know Emacs has other ways to access these,
but I find them handy as they are the same as in other applications. If
you are English-speaking then these are less important. Maybe that's the
reason the British don't want the Euro :=)
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Emacs on OS X - configuration package

[Jussi Piitulainen]

Piet van Oostrum writes:

> videoxfer wrote:
> 
>> In the carbon build it's either alt or meta, depending on the value
>> of the variable mac-command-key-is-meta.  Every carbon emacs user I
>> know sets this variable to nil,
> 
> Well, I don't. The main reason is that I would loose the
> Alt-keyboard function which gives me acces to non-ASCII characters,
> like the Euro sign and accented characters. Yes, I know Emacs has
> other ways to access these, but I find them handy as they are the
> same as in other applications. If you are English-speaking then
> these are less important. Maybe that's the reason the British don't
> want the Euro :=)

I went to a lot of trouble to have Alt as Meta and still get the most
important Alt-characters. These are all in ASCII: @${[\|]}. I have
Finnish keyboards, so there are keys for the letters I need for my own
language, and accent keys give most of the rest, though not all.

Now I type | as Alt-7 and \ as Shift-Alt-7 and so on, but Alt-c is M-c
and Alt-q is M-q, and Command-q does no harm. Works well. The biggest
loss is M-\, because I would have to type that as Shift-Alt-7, which
gives the character \.

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-03-01, Piet van Oostrum <piet@cs.uu.nl> wrote:
> Well, I don't. The main reason is that I would loose the Alt-keyboard
> function which gives me acces to non-ASCII characters, like the Euro sign
> and accented characters.


True.  You _can_ still enter many accented latin1-specific characters
with the option key even if option is bound to meta.  For instance I
can use opt-u in the usual mac way to enter ü, ö etc.  In fact I just
did.  But as you say, you can't get at everything this way, for
instance I can't use opt-s to enter ß (I did insert-ss to enter that
one).  

Re: Emacs on OS X - configuration package

[Jussi Piitulainen]

videoxfer writes:

> Piet van Oostrum wrote:
>
>> Well, I don't. The main reason is that I would loose the
>> Alt-keyboard function which gives me acces to non-ASCII characters,
>> like the Euro sign and accented characters.
> 
> True.  You _can_ still enter many accented latin1-specific
> characters with the option key even if option is bound to meta.  For
> instance I can use opt-u in the usual mac way to enter ü, ö etc.  In

Usually M-u is bound to upcase-word. If you simply set option to be
meta, that is what you get.

(Alt and option are names for the same key.)

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-03-01, Jussi Piitulainen <jpiitula@ling.helsinki.fi> wrote:
>> True.  You _can_ still enter many accented latin1-specific
>> characters with the option key even if option is bound to meta.  For
>> instance I can use opt-u in the usual mac way to enter ü, ö etc.  In
>
> Usually M-u is bound to upcase-word. If you simply set option to be
> meta, that is what you get.

In the carbon emacs with option bound to meta, option-u is both M-u
(upcase-word) and the umlaut prefix character.  If I type opt-u u I
insert the u-umlaut character into the buffer.  If I typed opt-u
opt-u, I upcase the word (this doubling is the price paid for the
convenience of using the familiar mac key gestures).  It's not a
matter of emacs key bindings afaik -- at that level M-u is
upcase-word, as usual. I'm pretty sure the handling of prefix
characters like option-u is handled earlier than that.

Re: Emacs on OS X - configuration package

[Jussi Piitulainen]

videoxfer writes:
> Jussi Piitulainen wrote:
>> Usually M-u is bound to upcase-word. If you simply set option to be
>> meta, that is what you get.
> 
> In the carbon emacs with option bound to meta, option-u is both M-u
> (upcase-word) and the umlaut prefix character.

So if you type `C-h c opt-u' it both says something like "M-u runs the
command upcase-word" and waits for the next keypress? If it does only
the latter, then opt-u is not the usual M-u.

I have a Carbon Emacs with opt as meta. Opt-u upcases a word. It does
not wait for anything. `Opt-u u' would upcase a word and insert u. I
did redefine several keys, with help from this newsgroup, but I don't
remember having to fight opt-u.

> If I type opt-u u I insert the u-umlaut character into the buffer.
> If I typed opt-u opt-u, I upcase the word

Then you may have option as meta and M-u as a prefix key. You do not
have opt-u as upcase-word. Else opt-u opt-u would upcase two words.

> (this doubling is the price paid for the convenience of using the
> familiar mac key gestures).

You don't seem to get what you bargained for, if simply pressing opt-u
does not insert a character.

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-03-02, Jussi Piitulainen <jpiitula@ling.helsinki.fi> wrote:
> So if you type `C-h c opt-u' it both says something like "M-u runs the
> command upcase-word" and waits for the next keypress? 

If you type 'C-h c opt-u' it does nothing, since it's waiting for the
completion of the prefix character.  As I said in the previous post,
the handling of opt-u (say) as a prefix key appears to be taking place
at lower level than an emacs key binding.  Only Andrew knows for sure...

If you type 'C-h c opt-u opt-u', it says "M-u runs the command
upcase-word" and it's done.


> I have a Carbon Emacs with opt as meta. Opt-u upcases a word. It does
> not wait for anything. `Opt-u u' would upcase a word and insert u. I
> did redefine several keys, with help from this newsgroup, but I don't
> remember having to fight opt-u.

I'm not fighting anything.  I deliberately enabled this because I find
it useful to be able to enter umlaut vowels (for instance) in this
way, since my fingers are trained to do this automatically. I'm
willing to type opt-u twice if I want M-u because I don't use it very
often. 


> Then you may have option as meta and M-u as a prefix key. 

Afaik emacs knows nothing about prefix keys; that's a mac thing.  I
don't think the standard emacs key processor even _sees_ the initial
opt-u.



> You don't seem to get what you bargained for, if simply pressing opt-u
> does not insert a character.

Do you run any form of macos?  Opt-u would never insert anything.
It's a prefix character that adds umlaut to whatever you type next (if
what you type next can take an umlaut).  Exactly the same thing
happens in carbon emacs, so I get exactly what I'm paying for.

Re: Emacs on OS X - configuration package

[Jussi Piitulainen]

videoxfer writes:
> Jussi Piitulainen wrote:
>> So if you type `C-h c opt-u' it both says something like "M-u runs
>> the command upcase-word" and waits for the next keypress?
> 
> If you type 'C-h c opt-u' it does nothing, since it's waiting for

I see it now. If you type it, that happens; if I type it, I get the
response "M-u runs ...". We have different keyboards. See below.

>> Then you may have option as meta and M-u as a prefix key. 
> 
> Afaik emacs knows nothing about prefix keys; that's a mac thing.  I
> don't think the standard emacs key processor even _sees_ the initial
> opt-u.

(I thought it would have been a prefix in the way that C-x and C-c
are, an Emacs thing. I understand now.)

>> You don't seem to get what you bargained for, if simply pressing
>> opt-u does not insert a character.
> 
> Do you run any form of macos?  Opt-u would never insert anything.
> It's a prefix character that adds umlaut to whatever you type next
> (if what you type next can take an umlaut).  Exactly the same thing
> happens in carbon emacs, so I get exactly what I'm paying for.

I run Mac OS X 10.3.2, Panther, and opt-u usually inserts u-umlaut. In
Carbon Emacs with opt as meta it upcases a word. I don't use it much
either, but I use M-c and M-l, and for me those are a similar case.

Finnish keyboards have ordinary keys for what you call a-umlaut and
o-umlaut, and for a-with-ring-above, and there is a separate prefix
key that serves as umlaut/dieresis, circumflex and tilde prefix, and
another prefix key that gives grave and acute accents. The latter two
behave like your opt-u. Our opt-u is not a prefix key.

Different hardware, different problems. That's why we had difficulty
understanding each other, but I hope it's clear now.

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-03-02, Jussi Piitulainen <jpiitula@ling.helsinki.fi> wrote:
> Different hardware, different problems. That's why we had difficulty
> understanding each other, but I hope it's clear now.

Yes, I see the source of the confusion.  I probably should have made
the deduction:  .fi ==> different keyboard than what I use...

Re: Emacs on OS X - configuration package

[David Steuber]

videoxfer <videoxfer@xfer.tv> writes:

> On 2004-03-01, Piet van Oostrum <piet@cs.uu.nl> wrote:
> > Well, I don't. The main reason is that I would loose the Alt-keyboard
> > function which gives me acces to non-ASCII characters, like the Euro sign
> > and accented characters.
> 
> 
> True.  You _can_ still enter many accented latin1-specific characters
> with the option key even if option is bound to meta.  For instance I
> can use opt-u in the usual mac way to enter ü, ö etc.  In fact I just
> did.  But as you say, you can't get at everything this way, for
> instance I can't use opt-s to enter ß (I did insert-ss to enter that
> one).  

I am seeing blocks/rectangles (default glyphs?) rather than proper
charcter glyphs in my Carbon Emacs build.  Is there a way for me to
fix that?  I am running a fairly recent CVS compile.  I don't recall
the date of my last checkout, but this has been a problem for a while
now.

-- 
Those who do not remember the history of Lisp are doomed to repeat it,
badly.

Re: Emacs on OS X - configuration package

[videoxfer]

On 2004-03-01, David Steuber <david.steuber@verizon.net> wrote:
>> True.  You _can_ still enter many accented latin1-specific characters
>> with the option key even if option is bound to meta.  For instance I
>> can use opt-u in the usual mac way to enter ü, ö etc.  In fact I just
>> did.  But as you say, you can't get at everything this way, for
>> instance I can't use opt-s to enter ß (I did insert-ss to enter that
>> one).  
>
> I am seeing blocks/rectangles (default glyphs?) rather than proper
> charcter glyphs in my Carbon Emacs build.  Is there a way for me to
> fix that?

These are the possibly relevant things in my .emacs:

  (set-terminal-coding-system 'iso-8859-1)

  (setq mac-keyboard-text-encoding kTextEncodingISOLatin1)

  (create-fontset-from-fontset-spec
    "-apple-monaco-medium-r-normal--10-*-*-*-*-*-fontset-monaco,
 ascii:-apple-monaco-medium-r-normal--10-100-75-75-m-100-mac-roman,
 latin-iso8859-1:-apple-monaco-medium-r-normal--10-100-75-75-m-100-mac-roman")

  ;; Only the font entry is relevant 
  (setq default-frame-alist '((width . 80)
			      (height . 50)
			      (font . "fontset-monaco")))

Re: Emacs on OS X - configuration package

[Stefan Monnier]

> I am seeing blocks/rectangles (default glyphs?) rather than proper
> charcter glyphs in my Carbon Emacs build.  Is there a way for me to
> fix that?  I am running a fairly recent CVS compile.  I don't recall
> the date of my last checkout, but this has been a problem for a while
> now.

M-x report-emacs-bug, with a recipe starting from `emacs -q --no-site-file'
or something equivalent (i.e. an empty .emacs file).


        Stefan