Emacs on GNUstep

[Adrian Robert]

Hi,

I've managed to get emacs compiled and running under GNUstep!

http://kamares.ucsd.edu/~arobert/GNUstep/emacs.html

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
experience).

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
OS X.

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.

-Adrian

--------------------------
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:

     [_listener updateServicesMenu];
     [_main_menu update];

   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.)