emacs-devel
[Top][All Lists]
Advanced

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

Re: Next release


From: YAMAMOTO Mitsuharu
Subject: Re: Next release
Date: Mon, 05 May 2008 08:52:25 +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 Sun, 04 May 2008 17:35:18 -0400, Chong Yidong <address@hidden> said:

>>> Yes, the merge had its share of problems, but the fact that
>>> Lorentey wasn't around made it worse.  But I don't know what
>>> unrelated change you may be thinking about.
>> 
>> Of course I can give concrete examples, which are Mac-specific.
>> But the point is: I found some, then how can I assure there's no
>> other?  Rather, I would doubt the quality and reliability of the
>> whole code from such kinds of changes.

> Would you prefer that other Emacs developers avoid touching the
> Carbon-specifics part of the Emacs tree, even if compilation breaks,
> so that you are the only one responsible for changes to that part of
> the code?  That might be an acceptable arrangement, if that is what
> you want.

I'd appreciate changes from experts on other area, of course.
I've been keeping the similarity of the Carbon-specific code not
only for consistency with other platforms but also those who are
familiar with other platforms but not with Carbon can easily find
and touch the part for changes that are common to several
platforms.
(BTW, that's one difference from the Cocoa/GNUstep port.)

The problem in the multi-tty case is, some changes that are
totally unrelated to multi-tty were mixed into the multi-tty
merger.  If it was intentional, that's unfair.  Otherwise, I
doubt if the author did that job with enough understanding of the
code.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

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