Re: Emacs on GNUstep

[Alex Perez]

On Fri, 8 Oct 2004, Adrian Robert wrote:

> Hi,
> 
> I've managed to get emacs compiled and running under GNUstep!
> 
> http://kamares.ucsd.edu/~arobert/GNUstep/emacs.html

Great, this is good news.
> 
> NOTE: This is not production status.  It is usable and stable with
>      my machine and usage, but there are outstanding issues.
It's still better than the previous status... :)

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

I will give you CVS admin access so you can commit your changes. E-mail me 
your sourceforge username privately.

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

Can you detail the reasons why (you think) it won't run under back-art?

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

As is often the case, this is all we have to work with.
> 
> 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?

I had actually started manually merging the NS-specific code into emacs 
21. This is no easy task, especially because some of the internal 
architecture of emacs changed significantly enough betweeen 20 and 21 to 
make things a royal pain in the ass.

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

Indeed. While I don't use emacs myself, I know that a lot of people do, 
and we do have steppers who use it regularly. I am sure they appreciate 
your work, as do I.

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

Yes, project center needs support for external editors, still, I think, 
but that should be fairly easy to fix. Serg, can you do this?

> 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.
Yes, it's long been my desire to see that carbon crud removed and the 
bulk of native cocoa code (with maybe a few ifdefs for mac-specific 
sections) working under both GNUstep and OS X. Since GNUstep is a GNU 
project, I think it makes sense.

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

You don't have to. I may yet still find time, but what I'd really like to 
find is an emacs programmer-user who wants to see this merge happen.

It should be noted that emacs is now using GNU Arch (also known as TLA). 
This means that maintaining a potentially destabilizing branch is easyly  
accomplishable. I really want to see this work become part of the 
canonical emacs.
[snip]
>      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.)

I think this is because the arrows are images, and not actually rendered. 
This is one of those things in GNUstep that needs a real solution.

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

It would be nice if this got fixed in -GUI...Alexander Malmberg might be 
able to help...

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

probably a back-xlib bug.

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

Indeed it could. Can someone please fix this?

Adrian, THANKS FOR ALL YOUR HARD WORK! I really appreciate it.

Cheers,
Alex Perez