>>>>>> "Malcolm" == Malcolm Purvis <malcolmp(a)xemacs.org> writes:
>>>>>
>
> Malcolm> For those who don't read comp.emacs.xemacs, Andrew Choi
> Malcolm> has announced a new port to XEmacs
>
> Heh, heh, heh. Let that be a lesson to those of you who believe in
> "no exceptions".
>
> Malcolm> It's a much more conservative effort which makes it
> Malcolm> easier to understand. It also builds using the standard
> Malcolm> './configure ; make ; make install' sequence rather than
> Malcolm> the existing convoluted process.
>
> That's easy enough to do with Pitts's version, of course, although
> internally much of the build would be done via Xcode.
>
> Malcolm> I find the combination attractive to work on. Others may
> Malcolm> think so too.
>
> It's not the way Mac applications are grown, and it doesn't even admit
> a word-for-word translation. I don't think this will attract any more
> new developers than the Windows port has (which is to say "zero"),
> except (obviously) for Andrew himself. Do you have reason to believe
> otherwise?
>
> I have always thought Pitts's port was very much in the spirit of
> XEmacs. Do it radical, do it right. Unfortunately, to a Mac user or
> developer it currently looks like somebody tried to write a parody of
> a Mac app and didn't quite succeed even at that. Without Pitts it's
> not going anywhere; I don't know how to get past the threads vs. stdio
> locking problem that currently prevents it from even starting on
> Panther. (Not that I know much about Mac OS X, but I'm the closest
> thing remaining to a champion/expert for the port.)
>
> Malcolm> I'd like this version to be adopted as the MacOS port
> Malcolm> with a view to incorporating it into the mainline in the
> Malcolm> nearish future.
>
> If Andrew is willing to join the Review Board and champion his port,
> and make sure it integrates with 22.0, that's fine with me. (That's
> also the only chance I see of attracting developers in the face of a
> well-established GNU Emacs port.) Otherwise it should wait until
> either 22.0 is released or we decide that's not going to happen any
> time soon.
I hate to disagree with Stephen, but I've never been able to get Pitts'
version to work. I don't like Xcode, except of course the GCC part.
It is very painful to move back and forth between Xcode and configure,
unless you really know Xcode (and then there really is no point).
I've been using Andrew's version of GNU Emacs for about 6 years
(going back to OS 9 even). He has supported the GNU Emacs ports
(OS 9 and OS X) completely satisfactorily IMHO. I'm sure that his
support of XEmacs would be no less. I think we should all be
encouraging this. His choice to use comp.emacs.xemacs rather
than xemacs-beta might be idiosyncratic, but it is understandable.
I myself can't keep up with xemacs-beta. So, I second Malcolm's
suggestion and I'd like to see this on the XEmacs Community News
RSN. If we can all agree, then I'd be willing to come up with a
patch to index.contents.
Thanks, Rodney