[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs with Cocoa/GNUstep
Re: Emacs with Cocoa/GNUstep
Wed, 27 Apr 2011 18:24:43 -0600
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
> 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.
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
> 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/
exception NSInternalInconsistencyException, reason: NSApp's run called
> 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.
> 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.
> 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 ?!