Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Mon, 03 Sep 2007 15:49:26 +0100, Jason Rumney <jasonr@gnu.org> said:

> Randal L. Schwartz wrote:
>> I might be misreading this, but does this mean that mac carbon is
>> essentially dead now, and won't be fixed, thanks to multi-tty being
>> merged?

> One developer, who is currently the main maintainer for the Carbon
> port, has expressed the view that merging the Cocoa port (Emacs.app)
> would be a better use of his time than continuing to maintain the
> Carbon port once the unicode branch is merged.

As it seems to be about me, maybe I should add a few words about that.

I think you mean something I said in the emacs-unicode list.  I also
said basically the same thing recently (before Dan made a multi-tty
port for Carbon with minimal tests):

  As for Mac, I'm planning to quit the development of the Carbon port
  for Emacs 23, as the Cocoa/GNUstep port will replace it on that
  version.  So, personally I don't care if multitty is incompatible with
  the current Carbon code as long as it is not for Emacs 22.x (x > 1).

  http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00310.html

But I didn't mean I'll help the development of the Cocoa/GNUstep port.

> It does not mean that others cannot continue to maintain the Carbon
> port if they feel it is necessary,

Right.

> nor does it mean that any effort to fix the bugs in the multi-tty
> functionality would be wasted, as most of the non-UI Carbon code
> will still be used by the Cocoa port.

If "the Cocoa port" means Emacs.app by Adrian Robert et al., that's
not true: it doesn't share the code with the Carbon port.  On the
other hand, recently I'm developing another Cocoa port (on Emacs 22)
that has a different design and policy.  It actually uses "most of the
non-UI Carbon code", and only the UI portions are reimplemented on
Cocoa.  So, I'd call it "Carbon+AppKit port" rather than a Cocoa port
(the AppKit framework provides UI portions of Cocoa).  It is actually
working well, and the new code is less than 6000 lines.  One of its
objectives is apparently to make the 64-bit version because UI
portions of Carbon is not going to be 64-bit.  (The current version of
the Carbon+AppKit port is just the first step and it still doesn't
work as a 64-bit binary.)

Currently the Carbon+AppKit port loses the destination to check in,
but I'm not in a hurry: actually, it does not provide any new or fancy
features users may want to see :-).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp