Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

On 11/24/07, Dan Nicolaescu <address@hidden> wrote:

> We are trying to minimize the number of files preloaded, if you look in
> loadup.el no other platform loads these files, you'd need to justify the
> need to load them.
>
> emacs-lisp/advice will 100% be rejected, if you need different
> functionality, just change the function, not advice it.

OK, I've dropped advice and its prereqs, dropped paren (because drop
mic-paren), and ns-mark-nav will be submitted separately.  All that is
left are easymenu and easy-mmode.  These are needed to ease the pain
in making the minor menu changes needed for platform convention in
ns-win.  Are they a problem?



>  > >  lisp/ns-grabenv.el                 |only
>  > >
>  > > Doesn't the Carbon port have the same problem that this file tries to
>  > > solve? Does GNUstep have this problem? Is the ns-* name appropriate
>  > > then?
>  >
>  > You are right this solves a problem mainly encountered on the Mac
>  > platform for the Cocoa port.
>
> Are you saying that the Carbon port does not have to deal with this issue.

There are multiple ways for users to tackle it.  Emacs.app includes
two (ns-grabenv.el and mac-fix-env binary), and some Carbon users take
these out of the Emacs.app dist and use them.  Many Carbon users use
Aquamacs, a distribution that includes its own approach to the problem
(basically auto-invoke something like ns-grabenv on startup).  Power
OS X users can and do work around the issue without any of these
tools.



>  > >  lisp/term/ns-win.el
>  >
>  > >    Are the deffaces really needed in this file?
>  >
>  > ns-working-text-face is needed.  paren-face-match-light will be
>  > removed along with mic-paren when/if a merge becomes imminent.
>
> That's not very productive for the people reviewing this code: if
> something won't be included, then drop it and keep it as local
> customization, it won't force unnecessary extra work on people trying to
> help with the merge.

OK , removed, will be reflected in next release.



> BTW, I just noticed this:
> (makunbound 'yank-menu-length)
> (defcustom yank-menu-length 40
>
> Use customize-set-variable instead. But even that would need
> justification for changing a default in a platform specific file.

Dropped (though IMHO the default of 20 is unnecessarily small).



>  > > I think you posted the changes to lisp/progmodes/cc-*.el to this
>  > > list. What keeps them from being checked in CVS? They are not related to
>  > > this port, just unnecessary overhead for you...
>  >
>  > They are still not accepted by the maintainer yet.  If they get
>  > accepted I can take them out.  Otherwise I feel they should at least
>  > be bundled as part of the port, because Objective-C is the primary
>  > development language for both Mac and GNUstep.
>
> Were the changes not reviewed or not accepted at all? If the former, I'd
> advice you repost them here, CCing RMS. In general he keeps track of
> submitted patches.

RMS and Alan Mackenzie seemed OK with acceptance, but I think Alan has
not had time to look at it since.  I'm not sure if maybe some
objection will be found.  See thread associated with:

http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01428.html



>  > > Also it seems that !GNUSTEP is the same as COCOA. Why not just use one 
> of them?
>  >
>  > I'm fine to make this change if people think it's easier to read.
>
> Yeah, the least amount of identifiers that one has to learn the meaning
> for, the better.

I'll drop COCOA and look into dropping GNUSTEP in favor of !MAC_OSX.
Although, to answer Yamamoto-san's question, building GNUSTEP under OS
X should be left possible, since people do install GNUstep on Macs.



>  > > Don't do any #ifdef MULTI_KBOARD, just assume it is always defined.

Done.



>  > Emacs.app does not include any icons.  Unless you're talking about the
>  > main app icon.  For now I think it's best to use a different one, so
>  > users know which version they are running.
>
> On X11, we don't have different icons for running with different
> toolkits...

For merging I will switch to the standard (notebook) icons used for
Carbon.  If I continue an enhanced binary distribution I'll use the
current Emacs.app icon.



> Please follow the example in other branches: place the ChangeLog files
> in the appropriate directories and call them ChangeLog.cocoa.
>
> For new files you just need a single entry: New file. Every single
> change to generic emacs code needs to have a ChangeLog entry describing
> it, even if it was done before you maintained the code.

OK, this will be done.


Adrian