[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs on GNUstep
From: |
Alex Perez |
Subject: |
Re: Emacs on GNUstep |
Date: |
Fri, 8 Oct 2004 10:45:07 -0700 (PDT) |
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