all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Adrian Robert" <adrian.b.robert@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: Emacs.app (Cocoa/GNUstep port) release and feature list
Date: Sat, 24 Nov 2007 13:39:26 +0300	[thread overview]
Message-ID: <55f7df060711240239p651eecp50739107676ff941@mail.gmail.com> (raw)
In-Reply-To: <200711232300.lANN08Up005153@oogie-boogie.ics.uci.edu>

On 11/24/07, Dan Nicolaescu <dann@ics.uci.edu> 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

  reply	other threads:[~2007-11-24 10:39 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
2007-11-24 10:39   ` Adrian Robert [this message]
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=55f7df060711240239p651eecp50739107676ff941@mail.gmail.com \
    --to=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.