all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@ics.uci.edu>
To: "Adrian Robert" <adrian.b.robert@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs.app (Cocoa/GNUstep port) release and feature list
Date: Fri, 23 Nov 2007 15:00:08 -0800	[thread overview]
Message-ID: <200711232300.lANN08Up005153@oogie-boogie.ics.uci.edu> (raw)
In-Reply-To: <55f7df060711230241y6aeee7cfr12e61c493002014b@mail.gmail.com> (Adrian Robert's message of "Fri, 23 Nov 2007 13:41:56 +0300")

"Adrian Robert" <adrian.b.robert@gmail.com> 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

  parent reply	other threads:[~2007-11-23 23:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-23 10:41 Emacs.app (Cocoa/GNUstep port) release and feature list Adrian Robert
2007-11-23 14:56 ` David Reitter
2007-11-23 15:25   ` YAMAMOTO Mitsuharu
2007-11-23 15:38   ` Adrian Robert
2007-11-23 15:29 ` Stefan Monnier
2007-11-23 16:10   ` Adrian Robert
2007-11-23 16:24     ` Stefan Monnier
2007-11-23 17:40       ` CHENG Gao
2007-11-25  6:58       ` Adrian Robert
2007-11-23 23:00 ` Dan Nicolaescu [this message]
2007-11-24 10:39   ` Adrian Robert
2007-11-24 16:33     ` Dan Nicolaescu
2007-11-25 11:17       ` Adrian Robert
2007-11-25 17:09         ` Dan Nicolaescu
2007-11-24 23:32     ` YAMAMOTO Mitsuharu
2007-12-01 12:30     ` Adrian Robert
2007-12-01 20:49       ` Stefan Monnier
2007-12-10 16:47         ` MAC_OS_X cpp macro? Stefan Monnier
2007-12-11  1:08           ` YAMAMOTO Mitsuharu
2007-12-11 18:57             ` Stefan Monnier
2007-12-12  0:07               ` YAMAMOTO Mitsuharu
2007-12-10 17:04         ` admin/CPP-DEFINES Stefan Monnier
2007-12-14 12:42           ` admin/CPP-DEFINES Eli Zaretskii
2007-11-24 11:37 ` Emacs.app (Cocoa/GNUstep port) release and feature list William Xu
2007-11-24 12:47   ` YAMAMOTO Mitsuharu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200711232300.lANN08Up005153@oogie-boogie.ics.uci.edu \
    --to=dann@ics.uci.edu \
    --cc=adrian.b.robert@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.