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: Sun, 25 Nov 2007 14:17:13 +0300 [thread overview]
Message-ID: <55f7df060711250317j469e5ff3r3e55be3eba50066f@mail.gmail.com> (raw)
In-Reply-To: <200711241633.lAOGXwA8029406@oogie-boogie.ics.uci.edu>
On 11/24/07, Dan Nicolaescu <dann@ics.uci.edu> 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
next prev parent reply other threads:[~2007-11-25 11:17 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
2007-11-24 16:33 ` Dan Nicolaescu
2007-11-25 11:17 ` Adrian Robert [this message]
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=55f7df060711250317j469e5ff3r3e55be3eba50066f@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.