From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Adrian Robert" Newsgroups: gmane.emacs.devel Subject: Re: Emacs.app (Cocoa/GNUstep port) release and feature list Date: Sun, 25 Nov 2007 14:17:13 +0300 Message-ID: <55f7df060711250317j469e5ff3r3e55be3eba50066f@mail.gmail.com> References: <55f7df060711230241y6aeee7cfr12e61c493002014b@mail.gmail.com> <200711232300.lANN08Up005153@oogie-boogie.ics.uci.edu> <55f7df060711240239p651eecp50739107676ff941@mail.gmail.com> <200711241633.lAOGXwA8029406@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195989448 29474 80.91.229.12 (25 Nov 2007 11:17:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Nov 2007 11:17:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 25 12:17:36 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IwFUW-0000Q3-3j for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2007 12:17:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IwFUH-0005XE-65 for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2007 06:17:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IwFUD-0005Vk-Cl for emacs-devel@gnu.org; Sun, 25 Nov 2007 06:17:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IwFUB-0005S4-37 for emacs-devel@gnu.org; Sun, 25 Nov 2007 06:17:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IwFUA-0005Rp-Rs for emacs-devel@gnu.org; Sun, 25 Nov 2007 06:17:14 -0500 Original-Received: from rv-out-0910.google.com ([209.85.198.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IwFUA-0003p2-Br for emacs-devel@gnu.org; Sun, 25 Nov 2007 06:17:14 -0500 Original-Received: by rv-out-0910.google.com with SMTP id c27so318047rvf for ; Sun, 25 Nov 2007 03:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=gS7b3Mc0iht0DbOBnzSy5R14YI25QbWqv+7jtT6FPnw=; b=lDfX3IaiSVozz32fRZiCxmjHMGcsP62ogVQgMc77NrQUTaMgZWXEMB9742y71X88+M5TOLLw9Hu7Ur2qAGg8YbkVBvYPpnKXJB4+4gzFZa1Rr1kaDy9vggZmryNsyncDx8Sq9D9PHqqptNXRWwVrxiYSF2KObXN84F1ku3J9EIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XsX64PYZykecqyuEmYl1/+LyZf5LYoq/br94nr+qi5CWrLQZqP9dt7XZCKjP3RczyJTERgj5cLJxGVamwqoXzUXo9GWeaPXnzHRXdLjWwNR8gdD3VP3b4/qSQaa5H8WrbJGzPPSlIQ12C+YPhXI6niD+Li4Y2FhJFR3dMDTMitU= Original-Received: by 10.140.147.18 with SMTP id u18mr577845rvd.1195989433555; Sun, 25 Nov 2007 03:17:13 -0800 (PST) Original-Received: by 10.140.185.19 with HTTP; Sun, 25 Nov 2007 03:17:13 -0800 (PST) In-Reply-To: <200711241633.lAOGXwA8029406@oogie-boogie.ics.uci.edu> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:84109 Archived-At: On 11/24/07, Dan Nicolaescu 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