Re: Mac OS-compatible ports (was: C-g crash in C-x C-f (OSX Lion))

[YAMAMOTO Mitsuharu]

On 2012/01/01, at 10:47, YAMAMOTO Mitsuharu wrote:

> 
> On 2011/12/31, at 22:22, Ted Zlatanov wrote:
> 
>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
>> "in its defense" it is compatible with GNUstep by using the Cocoa API,
>> which your port isn't.  So, to make the current situation clear, the
>> Mac OS port choice is between:
>> 
>> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
>> with GNUstep and can work there (it needs lots of work though).  Apple
>> has repeatedly stated Cocoa is the preferred API for Mac OS X
>> developers, especially for new software.
>> 
>> 2) your Carbon-based port: works on Mac OS X well, can't be compatible
>> with GNUstep.  Apple has not been clear about Carbon's future, even
>> though Carbon seems to be well entrenched at this point.
> 
> As I've been repeatedly saying, the Mac port uses Cocoa for its
> GUI implementation.  If you call the Mac port Carbon-based, lots
> of the applications including those bundled with Mac OS X such as
> Safari.app should also be called Carbon-based.

Also, I would like to note that some of recent improvements to
Mac OS X and iOS are provided outside Cocoa, especially if they
are not directly related to GUI.  They are not classified as
Carbon, but they are also C APIs and not provided by GNUstep.
For example, Grand Central Dispatch (GCD) I mentioned in the
`select' emulation without periodic polling is a C API and
provided by both Mac OS X and iOS, but not by GNUstep.

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00694.html

The Core Text framework I'm using for the font backend driver in
the Mac port is also a C API.  Interestingly, in iOS Apple
provides an advanced low-level text layout API (Core Text) only
at C level, rather than copying such API (NSLayoutManager etc.)
from Mac OS X Cocoa AppKit to iOS UIKit.  I think this implies
Apple's preference of C API to Cocoa for advanced low-level tasks
that applications such as text editors want to use.

Because the Mac port already uses Cocoa AppKit for GUI, the
argument about Apple's preference of Cocoa to Carbon (with
respect to GUI) you made above is rather pointless.  I even have
an impression that the Mac port usually behaves more like other
Cocoa applications than the NS port does.

  http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00735.html

                                     YAMAMOTO Mitsuharu
                                address@hidden