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: Sat, 24 Nov 2007 13:39:26 +0300 Message-ID: <55f7df060711240239p651eecp50739107676ff941@mail.gmail.com> References: <55f7df060711230241y6aeee7cfr12e61c493002014b@mail.gmail.com> <200711232300.lANN08Up005153@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 1195900785 19273 80.91.229.12 (24 Nov 2007 10:39:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Nov 2007 10:39:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 24 11:39:53 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 1IvsQP-000107-EL for ged-emacs-devel@m.gmane.org; Sat, 24 Nov 2007 11:39:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvsQA-0001nK-RP for ged-emacs-devel@m.gmane.org; Sat, 24 Nov 2007 05:39:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IvsQ6-0001mr-Os for emacs-devel@gnu.org; Sat, 24 Nov 2007 05:39:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IvsQ5-0001m9-BO for emacs-devel@gnu.org; Sat, 24 Nov 2007 05:39:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvsQ4-0001ln-Vd for emacs-devel@gnu.org; Sat, 24 Nov 2007 05:39:29 -0500 Original-Received: from rv-out-0910.google.com ([209.85.198.191]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IvsQ4-0002Tn-3B for emacs-devel@gnu.org; Sat, 24 Nov 2007 05:39:28 -0500 Original-Received: by rv-out-0910.google.com with SMTP id c27so75435rvf for ; Sat, 24 Nov 2007 02:39:26 -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=dW3kTnTLA3DpBeoo55EqlRiO9sHedAGR5AvlxY2uzsc=; b=vNSOQ9lSap4VaRdC0Mt+0oObhmf8lDaM77ecDoFQVe8m6i2itT7JwEaRHfMA9VpFtuNOFYVVqb1pvWGU4b+7Q0LZt2nY4FwLPs+JHYALliZDT2ZjUK31WnJVvCOsZuD6V6J+nxECsyGCbByivtdDqzdzYSvwx5km9k2r4QuWV2Q= 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=fi8ysgrHn32FziZRTRb9aQaLaV4WiNmquoLHj0tjlRJmH1lOTPoAv7DQEJf4OYRVPoU0cVz7pJVyjEJAF2KRNQRuhNW3E+rPoo0NyOl3DhX6YFXXcBOOw4BrnoNOPLadIWhz5v3Z2arBZPmL99eMz/YyBaSP5engyQa+e1PHE70= Original-Received: by 10.140.226.14 with SMTP id y14mr136830rvg.1195900766602; Sat, 24 Nov 2007 02:39:26 -0800 (PST) Original-Received: by 10.140.185.19 with HTTP; Sat, 24 Nov 2007 02:39:26 -0800 (PST) In-Reply-To: <200711232300.lANN08Up005153@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:84041 Archived-At: On 11/24/07, Dan Nicolaescu 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