Re: Emacs with Cocoa/GNUstep

[Germán Arias]

On mié, 2011-04-27 at 20:13 +0100, David De La Harpe Golden wrote:
> 
> Probably not a whole lot.... FWIW, I built it successfully several times 
> a few months back, and though it was not really especially useful once 
> built, it was not completely unusable either, it was working enough for 
> me to debug some pasteboard interaction issues without having access to 
> macosx.
> 
> I'm not personally up to doing much it about it at the moment, so here 
> are some notes (Stefan: mostly same ones I passed offlist to you at the 
> time) as a braindump, some of the below is probably obsolete:

Thanks, Stefan sent me a copy of that email some days ago.

> 
> First and foremost, DO NOT use any debian packages of GNUstep at time of 
> writing, they're obsolete and hopelessly buggy, especially on 64-bit.  I 
> wasted basically a weekend's worth of emacs-time that way, I switched to 
> an svn checkout of GNUstep installed to /usr/local/GNUstep and was up 
> and running fairly rapidly.
> 
> GNUstep itself is fairly painless to build from source (though n.b. I am 
> used to underdocumented build scripts from hell from work, my perception 
> may be skewed), the most tricky bit was getting building the 
> gnustep-back backend right, so that I could use cairo.
> 
> http://wiki.gnustep.org/index.php/GNUstep_Installation_Process
> 

I'm a contributor to GNUstep project since 2 years ago. So I really
don't have problems to install it from source. In fact I have more or
less (with some additions from SVN) the latest stable release of
GNUstep. And many apps that run perfectly.


> The other build-time issue is that emacs "./configure --with-ns" doesn't 
> seem to discover the ObjC headers properly in the gnustep case - 
> specifying CPPFLAGS "fixed" that, but I suspect TRT would be to have 
> emacs' configure use "gnustep-config --objc-flags" to discover the flags 
> (or maybe just $GNUSTEP_MAKEFILES and the right part of gnustep's 
> Makefiles, but gnustep-config seems interesting 'cos it apparently works 
> much like other blah-config type tools).

./configure --with-ns works fine form me (with stable release of
GNUstep).

> 
> I wouldn't say it is _totally_ unusable, but neither is it at all 
> pleasant .  There are probably plenty more smaller issues that I'm 
> presently not noticing given the big ones:

I tried Emacs.app like a year ago. I don't remember exactly what
version. I tested it and worked (with problems and sometimes crashed).
But currently, when I try to launch it I get the error:

address@hidden:~/Instalados/emacs$ openapp ./nextstep/Emacs.app/
/home/german/Instalados/emacs/nextstep/Emacs.app/Emacs: Uncaught
exception NSInternalInconsistencyException, reason: NSApp's run called
recursively


> 
> 0. Make sure the relevant gnustep daemons are running.
> 
> I mean the gpbs / gdnc /gdomap  daemons. Not really an emacs problem, 
> and documented in the gnustep docs, just something to be aware of.
> 
> gpbs is particularly important, as it's the GNUstep PasteBoard Server, 
> 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 
> it doesn't handle being resized by the window manager, you have to 
> (set-frame-width/height) from within emacs for it to work.  I guess 
> macosx handles resizing differently.
> 
> 2. repaint
> 
> There are nasty repaint issues sometimes too upon partial scrolling, a 
> bit like the ones you used to see on w32 emacs under wine.  A 
> page-scroll up and down has thus far largely dispelled them when they 
> occur. Some of the colors seem way off (my yellow-on-black fringes come 
> out cyan-on-white).
> 
> 3. toolbar/scrollbar.
> 
> The toolbar doesn't work, and the scrollbars only work sometimes, but 
> 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 
> computation isn't always right I guess, with one font I ended up with 
> something like a 3-pixel high minibuffer.
> 
> Remember that GNUstep also has multiple graphics backends with different 
> font behaviours, I used the cairo backend which reputedly has slightly 
> poorer font rendering than art, but OTOH worked.
> 
> Remember to try with "openapp Emacs -Q", because your ~/.emacs (which 
> gnustep will see) might be setting a problematic font, mine initially was.
> 
> It sometimes makes "interesting" font choices itself, I don't know where 
> 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 
> keyboard modifier mapping so that the keys in ns emacs ultimately wound 
> up similar to x11 emacs with its out-of-box defaults.
> 
> http://www.gnustep.org/resources/documentation/Developer/Back/General/DefaultsSummary.html
> 
> I used (with Help on Super_R because I wanted to see what it did, turns 
> 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 
> when there's input i.e. wiggle the mouse to make stuff happen ?!
>