[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Emacs on GNUstep
Emacs on GNUstep
Fri, 08 Oct 2004 10:10:19 -0400
I've managed to get emacs compiled and running under GNUstep!
NOTE: This is not production status. It is usable and stable with
my machine and usage, but there are outstanding issues.
I started with the version distributed as "Emacs On Aqua" at
http://emacs-on-aqua.sf.net . This version traces its lineage back
to an original port to NeXTstep by Carl Edman, which was
successively modified for OpenStep, Rhapsody, and OS X, and updated
most recently to GNU emacs 20.7.
Compilation was not that bad; I just added a few GNUSTEP #ifdefs
here and there. Getting things running smoothly was tougher. I
encountered a number of issues with the GUI lib. And I could only
get it running with the Xlib backend. Emacs makes a number of tough
demands on the GNUstep environment, not least because it runs its
own event loop and graphical update management. Nonetheless, this
shouldn't fundamentally conflict with GNUstep since it ran on all
the previous *steps (and was quite stable on NeXTstep in my own
I've listed at the end the issues I encountered, most of which I made
fixes for. A patch against most recent CVS (just post-0.94) is
available on the web page. It would be great if people with more
knowledge than myself could take a look at these. We may want to
commit some (in polished form), and perhaps reject others. There
are a number of cases where the Apple/OpenStep documentation is not
clear on something, but the existence of code in ns-emacs implies
that things in practice worked in a certain way.
OK, the port still needs a lot of work (see list of issues in the
web README), and it's also not the latest and greatest emacs 21.
Where do things go from here?
First, getting it working better has been and can continue to be a
means of flushing out bugs and important implementation gaps in the
GNUstep libraries. Help is welcome here.
Second, the second-newest version of the best editor in the known
universe is still a pretty darn good editor. ;-) In addition to just
using it as a standalone GNUstep application, we could think about
making it available as an edit panel or distributed objects server
in a variety of places in GNUstep (e.g., Project Center).
Third, speaking ideally and optimisically, this port gets solidified
on both GNUstep and OS X, then gets updated to emacs-21 (a big job),
and makes it into the GNU emacs tree as officially supported. The
current OS X emacs in the tree is Carbon-based, and did not have a
maintainer last I checked a few months ago. Moreover, I think there
are those who would be pleased to see a version of emacs in the tree
that supports GNUstep as well as OS X, rather than just the non-free
I am NOT volunteering as said maintainer or to do the port-to-21.
However I'm willing to coordinate improvement of the 20.7 version,
if others have interest in helping with this. I've put the source
code on the web page mentioned above.
List of GUI issues:
1) NSBestDepth() assumes bool arg exactMatch is non-nil. On OS X
and prior, this was not the case. (FIXED in patch)
2) NSColorList -initWithName:FromFile: assumes name given is
directory, not file. On OS X, this is not the case. (FIXED)
3) NSColorList cannot load ASCII color list .clr file. (FIX
started; only ARGB lists supported so far. This allows
to read "Emacs.clr", which incidentally is where the "Emacs"
color list comes from on OS X systems.)
4) NSMenuItem with submenu in GNUstep sets target by default to
'self', whereas in OS X and prior it appears to be set to the
submenu. (NOT FIXED. This might be reliance on an
implementation "feature"?) Also, with menus, menu items with
submenus do not send the action they were set to, because this is
replaced by the parent menu's submenuAction. Again, behavior on
other implementations differs.
5) [NSApplication -run] will call -finishLaunching every time it is
called, even if the application was previously started and
stopped (-stop). The Apple docs say (and the emacs impl depends
on) that [NSApp run] after a -stop: results in restarting the
loop, not relaunching the entire app. (FIXED, but should be
checked for correctness.)
6) In the main loop inside [NSApplication -run], the following is
called on most events, including keyUp, keyDown, and mouse drags:
Is this really needed? It seems excessive overhead to have on
every keystroke and mouse drag.
(PARTIALLY CHANGED. Took out key and scroll wheel events.)
7) [NSFont userFixedPitchFontOfSize: 0] returns 'Courier' in
anti-aliased Xlib backend, however it is not a fixed-pitch font.
(It IS the same as what shows up under 'Courier' in the GNUstep
font panel though.) Running 'xfontsel' shows (non-Xft) X thinks
"Courier" is fixed-pitch on my machine, and Mozilla, which does
access Xft fonts also shows a fixed-pitch font under
"Courier". This might a problem in the X back-end's font
cataloging? (NOTHING DONE.)
8) NSScroller does not accomodate scrollbars other than default
width; if subclass overrides +scrollerWidth, the width of the bar
itself is changed, but not the width of the buttons.
(PARTIALLY FIXED. Made previous static constant 'buttonsWidth'
into an instance variable and set based on +scrollerWidth.
However this seems to lead to problems with scrollbars narrower
than normal by more than a few pixels, and the button arrows in
particular seem to not adjust the the new width.)
9) [NSCursor +setHiddenUntilMouseMoves] does not appear to work
properly, at least in Emacs with Xlib backend. The cursor will
flash briefly off and/or to bare 'X' cursor (as if no window is
selected), then back on. May have to do with other NS AppKit
processing going on. (DISABLED in Emacs code.)
10) Resizing an xlib-backend window in WindowMaker seems to cause a
windowDidResize notification can be sent at the end, but no
windowWillResize events. (WORKED AROUND in Emacs code.)
11) [NSEvent -timestamp] seems to be returning milliseconds since
system startup, whereas Apple docs say it is seconds. Other
docs on NSTimeInterval, which is the type returned, also say
that this represents a time in seconds. Note, this type of
milliseconds-seconds confusion could be related to the
observation about seemingly excessive polling timeouts in
NSRunLoop. (WORKED AROUND in Emacs code.)
- Emacs on GNUstep,
Adrian Robert <=
- Re: Emacs on GNUstep, Magnus Henoch, 2004/10/08
- Re: Emacs on GNUstep, Jens F. Prinz-Sander, 2004/10/08
- Re: Emacs on GNUstep, Alex Perez, 2004/10/08
- Re: Emacs on GNUstep, Stefan Kleine Stegemann, 2004/10/08
- Re: Emacs on GNUstep, Marko Riedel, 2004/10/08
- Re: Emacs on GNUstep, Michael Baehr, 2004/10/08
- Re: Emacs on GNUstep, Fred Kiefer, 2004/10/10