[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon port emacs-unicode-2 build problem under MacOSX

From: YAMAMOTO Mitsuharu
Subject: Re: Carbon port emacs-unicode-2 build problem under MacOSX
Date: Thu, 08 Nov 2007 10:27:45 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Wed, 07 Nov 2007 08:19:07 -0600, Ted Zlatanov <address@hidden> said:

YM> What is "better integration with the MacOS", concretely?

> You and I could look through the ChangeLog and see all the
> differences.  As an example, the MacOS font and color pickers are
> available.  I think those are much better than the default
> cross-platform font/color pickers.

The Font Panel also is accessible from the Carbon port, via M-x
mac-font-panel-mode RET or Options -> Show/Hide -> Font Panel.  I
think making it global minor mode is a cleaner integration to Emacs
because it behaves as a non-modal floating panel just like the

Though I have an implementation of the Color Picker from the Font
Panel, I didn't checked it in because I didn't think it much useful,
no counterparts found in other platforms, and there was a nasty bug in
the Carbon Color Picker that its window doesn't disappear in some

YM> In what sense the font rendering in the Carbon port is worse?

> According to the ChangeLog they have improved several aspects of the
> font rendering; to me it looks better.  I could be wrong.

I'm asking the bases of your words, "after trying the Cocoa port, it's
actually much better than the Carbon port".  Without the concrete and
specific bases, you shouldn't have said so.

YM> And I don't think the Preference dialog that can't be controlled
YM> from Emacs Lisp is suitable for Emacs.

> I don't know about this.  I think this is a good thing because it
> works better for new users, and the regular Customize interface is
> still available under Options->Customize Emacs.  On the other hand,
> it's inconsistent with other platforms to have a special preferences
> dialog.

That might be good for a particular "distribution", but we are talking
about merging into Emacs core.  I would not add such a feature that
there are no counterparts in other platforms, unless it is too

Also, I'd give priority to implement fundamental features such as C-g
handling rather than fancy but superficial ones.  If you have been
watching the Carbon port in CVS, you'll notice that the proxy icons
and the font panels are added much later.  I don't know the current
status of the Cocoa port, but as of the last release, it still doesn't
handle C-g properly.

YM> It says about the *GUI* APIs in Carbon, not the whole Carbon APIs.
YM> That's why I'm making the Carbon+AppKit port (for Emacs 22) mentioned
YM> elsewhere:

YM>   http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg00395.html

> Note the Cocoa port offers GNUstep compatibility, which Richard has
> mentioned is important.  This may be important to the Emacs project;
> I don't have an opinion.

The importance of the GNUstep port doesn't affect the inclusion of the
Carbon+AppKit port to the later versions of *Emacs 22*.  Also, I've
been rather encouraging the merge of the Cocoa port to Emacs 23
(otherwise, I would still be working on the Carbon port for Emacs 23).

> I can look at your port too.  But I can't find it online.  Is it
> available?  I'll gladly test it, offer suggestions, etc. if you need
> that assistance.  It's hard to say more about your work or compare
> it with the Cocoa port otherwise.

It'll be available after the Emacs 22.2 release, if its inclusion is
allowed.  If you want to see how it behaves, just test the Carbon
port.  They are pretty much the same except `deprecated' warnings :-p

> Thank you for the information.  Sounds like Carbon is only
> deprecated selectively (the GUI portions as you mentioned) so it's
> not as dead as I thought.

And even with GUI, two major Apple apps, Finder and iTunes, are also
implemented as Carbon apps.

                                     YAMAMOTO Mitsuharu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]