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

[Adrian Robert]

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

>     (progn
>       (load "emacs-lisp/easymenu")
>       (load "emacs-lisp/easy-mmode")
>       (load "view")
>       (load "help-mode")
>       (load "help-fns")
>       (load "emacs-lisp/advice")
>       (load "ns-mark-nav")
>       (load "paren")
>
> Are these acceptable to be preloaded in platform specific code? IMHO no.

Could you elaborate on this?  These are loaded because setup in ns-win
needs them.    Is there some detrimental effect in loading them now
that ns-win must be loaded pre-dump?



>  lisp/mic-paren.el                  |only
>
> This is unrelated to the port, either submit separately or drop it.

Will do so.



>  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.  However it currently names all its
functions with the "ns-" prefix, so it seemed inappropriate to use
"mac-".  It could also have some use on GNUstep or other platforms if
the user edits his/her .cshrc after starting emacs.  So theoretically
it could be added to emacs core lisp functionality, but I would
recommend to extend it to work on Windows as well first.



>  lisp/ns-mark-nav.el                |only
>
> This does not seem to be specific to the port, why not submit is separately?

It is generic functionality, it could be submitted separately if it is
of interest.



>  lisp/term/ns-win.el
>
>    The functions/variables in here should either be called ns-* or x-*

OK.




>    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.



> 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.



> The new #defines: HAVE_NS GNUSTEP COCOA COCOA_EXPERIMENTAL_CTRL_G
>
> Why not HAVE_GNUSTEP and HAVE_COCOA too?

HAVE_XX seems to be standard for the overall windowing system / port
being used: HAVE_XWINDOWS, HAVE_NTGUI.  GNUSTEP and COCOA are platform
indicators, like DARWIN, MAC_OS8, GNU_LINUX, or VMS.  I would use
"MAC_OSX" instead of COCOA, but that is already used by the Carbon
port to mean essentially HAVE_CARBONGUI.



> 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.



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

I don't understand this.  There is lots of #ifdef MULTI_KEYBOARD in
the emacs code.



> Can the icons be shared with the Carbon port?

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.



> Is the nextstep/compile script really needed? Wouldn't
> ./configure && make
> work on this platform?

With a little work it would not be needed.  It is there to pick up
environment variable settings (GNUstep) and to complete packaging
operations into the .app (both platforms).  it also makes building
easier for end users, because this port is distributed directly right
now to the user community.



> You probably know RMS won't allow this code to be checked in without
> proper ChangeLogs...

There is nextstep/ChangeLog reflecting everything during my
maintainership period.  I don't think anything from the years previous
to that will be available.


> I hope this helps.

Thanks much for this feedback.


Adrian