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

[Dan Nicolaescu]

"Adrian Robert" <address@hidden> writes:

  > Hi,
  > 
  > Release 9.0-rc3 for the GNUstep and OS X / Cocoa port of the GNU Emacs
  > unicode-2 is available at http://emacs-app/sf.net
  > 
  > This release brings with it the multi-TTY merge (mixed GUI/TTY
  > sessions not yet supported though), and a number of bug fixes and
  > minor enhancements.  GNUstep support is untested for this release;
  > please contact me off-list if you have a GNUstep installation and are
  > willing to try it out.
  > 
  > In view of the prospects for upcoming merge into CVS, it was suggested
  > that a list of user-visible differences in this port from other
  > platforms be posted.  See below.  A couple of general points should be
  > noted:

Thanks for doing this!

Here are a few observations from quickly scanning the code: 

In loadup.el:

(if (featurep 'ns-windowing)
              ^^^^^^^
              Some better name here? There's no identifier in emacs that
              contains "windowing"

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

These files: 

 lisp/erc/erc-nicklist.el           |only
 lisp/net/tramp-util.el             |only
 lisp/net/tramp-vc.el               |only
 lisp/tumme.el                      |only
 src/s/umips.h                      |only

have been deleted from Emacs CVS

 lisp/mic-paren.el                  |only

This is unrelated to the port, either submit separately or drop it.

 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?

 lisp/ns-mark-nav.el                |only

This does not seem to be specific to the port, why not submit is separately?

 lisp/term/ns-win.el

   The functions/variables in here should either be called ns-* or x-*
   
   (setq transient-mark-mode t
   This needs to be a function call, not setq
   
         highlight-nonselected-windows nil
   Already the default
         delete-selection-mode t
   As above
   
         search-highlight t
         query-replace-highlight t
         split-window-keep-point t
   All are already the default
         mouse-copy-selection nil
   Non-existent variable
         frame-title-format t
         icon-title-format t)
   These might be incorrect
   
   (mouse-wheel-mode 1)
   Already done by default.
   
   Are the deffaces really needed in this file?
   

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

The comments in the ns*.m files use both // and /**/. Why not
standardize on /**/? That would make the sources consistent with the
rest of emacs, and it would be easier to move code from .m files to .c
files (if it's ever needed). 

The new #defines: HAVE_NS GNUSTEP COCOA COCOA_EXPERIMENTAL_CTRL_G

Why not HAVE_GNUSTEP and HAVE_COCOA too? 

Also it seems that !GNUSTEP is the same as COCOA. Why not just use one
of them?

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

Can the icons be shared with the Carbon port?

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

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


I hope this helps.

            --dan