From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Emacs with Cocoa/GNUstep Date: Wed, 27 Apr 2011 20:13:51 +0100 Message-ID: <4DB86AEF.7060809@harpegolden.net> References: <1303864750.11832.3.camel@german-desktop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1303931649 27200 80.91.229.12 (27 Apr 2011 19:14:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Apr 2011 19:14:09 +0000 (UTC) Cc: Emacs To: german@xelalug.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 27 21:14:05 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QFABW-0005qN-3n for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2011 21:14:02 +0200 Original-Received: from localhost ([::1]:40506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFABV-0002sx-If for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2011 15:14:01 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFABR-0002sq-GG for emacs-devel@gnu.org; Wed, 27 Apr 2011 15:13:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFABP-00048x-Qd for emacs-devel@gnu.org; Wed, 27 Apr 2011 15:13:57 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:50941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFABP-00048q-LX for emacs-devel@gnu.org; Wed, 27 Apr 2011 15:13:55 -0400 Original-Received: from [87.198.47.56] (87-198-47-56.ptr.magnet.ie [87.198.47.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 7C227683FC; Wed, 27 Apr 2011 20:13:53 +0100 (IST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Icedove/3.1.9 In-Reply-To: <1303864750.11832.3.camel@german-desktop> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 65.99.215.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138855 Archived-At: On 27/04/11 01:39, Germ=C3=A1n Arias wrote: > Hi, I'm trying to run emacs with GNUstep, but it seems to be totally > broken. So my question is if someone is running emacs with Cocoa and if > it works fine. Because with latest gnustep packages don't work (compile > but can't run). And after the last update in file configure.in, the > class nsmenu.m can't compile. So I can guess there isn't testing in > GNUstep/Cocoa. Probably not a whole lot.... FWIW, I built it successfully several times=20 a few months back, and though it was not really especially useful once=20 built, it was not completely unusable either, it was working enough for=20 me to debug some pasteboard interaction issues without having access to=20 macosx. I'm not personally up to doing much it about it at the moment, so here=20 are some notes (Stefan: mostly same ones I passed offlist to you at the=20 time) as a braindump, some of the below is probably obsolete: First and foremost, DO NOT use any debian packages of GNUstep at time of=20 writing, they're obsolete and hopelessly buggy, especially on 64-bit. I=20 wasted basically a weekend's worth of emacs-time that way, I switched to=20 an svn checkout of GNUstep installed to /usr/local/GNUstep and was up=20 and running fairly rapidly. GNUstep itself is fairly painless to build from source (though n.b. I am=20 used to underdocumented build scripts from hell from work, my perception=20 may be skewed), the most tricky bit was getting building the=20 gnustep-back backend right, so that I could use cairo. http://wiki.gnustep.org/index.php/GNUstep_Installation_Process The other build-time issue is that emacs "./configure --with-ns" doesn't=20 seem to discover the ObjC headers properly in the gnustep case -=20 specifying CPPFLAGS "fixed" that, but I suspect TRT would be to have=20 emacs' configure use "gnustep-config --objc-flags" to discover the flags=20 (or maybe just $GNUSTEP_MAKEFILES and the right part of gnustep's=20 Makefiles, but gnustep-config seems interesting 'cos it apparently works=20 much like other blah-config type tools). I wouldn't say it is _totally_ unusable, but neither is it at all=20 pleasant . There are probably plenty more smaller issues that I'm=20 presently not noticing given the big ones: 0. Make sure the relevant gnustep daemons are running. I mean the gpbs / gdnc /gdomap daemons. Not really an emacs problem,=20 and documented in the gnustep docs, just something to be aware of. gpbs is particularly important, as it's the GNUstep PasteBoard Server,=20 and without it, clipboard/primary/secondary just ain't gonna work. http://gnustep.made-it.com/BuildGuide/index.html#GNUSTEP.SERVICES 1. frame resizing. The single most major annoyance (or at least tied with repaint) is that=20 it doesn't handle being resized by the window manager, you have to=20 (set-frame-width/height) from within emacs for it to work. I guess=20 macosx handles resizing differently. 2. repaint There are nasty repaint issues sometimes too upon partial scrolling, a=20 bit like the ones you used to see on w32 emacs under wine. A=20 page-scroll up and down has thus far largely dispelled them when they=20 occur. Some of the colors seem way off (my yellow-on-black fringes come=20 out cyan-on-white). 3. toolbar/scrollbar. The toolbar doesn't work, and the scrollbars only work sometimes, but=20 it's not like I use either much. The menu bar is fine. 4. choice of fonts and gui backend: Wrong choice of font can render it difficult to use too - its metric=20 computation isn't always right I guess, with one font I ended up with=20 something like a 3-pixel high minibuffer. Remember that GNUstep also has multiple graphics backends with different=20 font behaviours, I used the cairo backend which reputedly has slightly=20 poorer font rendering than art, but OTOH worked. Remember to try with "openapp Emacs -Q", because your ~/.emacs (which=20 gnustep will see) might be setting a problematic font, mine initially was= . It sometimes makes "interesting" font choices itself, I don't know where=20 it found some sort of comic-sans alike on my system but it did. 5. Non-latin chars. Doesn't seem to do well here at all. 6. keyboard modifier mapping One thing that helped a lot was to reconfigure the gnustep-level=20 keyboard modifier mapping so that the keys in ns emacs ultimately wound=20 up similar to x11 emacs with its out-of-box defaults. http://www.gnustep.org/resources/documentation/Developer/Back/General/Def= aultsSummary.html I used (with Help on Super_R because I wanted to see what it did, turns=20 out ns emacs treats it as Hyper...): NSGlobalDomain GSFirstControlKey Control_L NSGlobalDomain GSSecondControlKey Control_R NSGlobalDomain GSFirstAlternateKey Alt_L NSGlobalDomain GSSecondAlternateKey NoSymbol NSGlobalDomain GSFirstCommandKey Super_L NSGlobalDomain GSSecondCommandKey NoSymbol NSGlobalDomain GSFirstHelpKey Help NSGlobalDomain GSSecondHelpKey Super_R 7. [new since I passed this to Stefan]. No timers/idle??? Timers and idle stuff mostly not running, I think. Emacs processes stuff=20 when there's input i.e. wiggle the mouse to make stuff happen ?!