[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: Support (or not) for Emacs 21, and XEmacs

From: Carsten Dominik
Subject: Re: [Orgmode] Re: Support (or not) for Emacs 21, and XEmacs
Date: Sun, 18 Apr 2010 16:03:42 +0200

Hi Michael,

On Apr 18, 2010, at 10:22 AM, Michael Sperber wrote:

Hi Carsten,

many thanks for your e-mail!  (And many thanks for your work on
org-mode, which is the best piece of software I've started using for a
few years.)

Carsten Dominik <address@hidden> writes:

However, I have recently more and more the feeling how having to
cater for several Emacs versions is a drag.

I understand and would feel the same in your situation.  So I was
wondering if I could make it easy enough for you so org-mode could keep
the XEmacs code in.

My feeling was also that the interest in the XEmacs side for
Org-mode is low.  To my knowledge there is no Org-mode package for
XEmacs, and the number of user on the mailing list seems to be very

Right.  However, the reason why this is so is trivial: org-mode is
GPLv3, and thus can't be a package for XEmacs, which is currently still
GPLv2.  (There has been a long and tedious discussion of this over in
XEmacs land which I'd like to spare you from.)  However, we've pretty
much resolved the GPLv3 issues over the past few months, and I hope that
we'll have a GPLv3 XEmacs very soon.  At which point I'll personally
make an XEmacs package.

So let me start with a question:  Is XEmacs still alive, innovative?
There has been no major release (it seems to me) for a very long time. It was my feeling that the XEmacs project is on its way to a slow death.
I may be wrong about this.

Development, which was slow for a long time, has recently picked up
significantly.  Releases are a problem, I admit: The developers
essentially all use the development branch, which is by now vastly
different from the 21.4 release.  (Also, the GPLv3 issue has kept us
from being able to merge Emacs code for a long time.)  But we'll do a
release at some point.

You propose to help.  One way to go would be to continue a branch
based on Org-mode 6.35, and to merge any new stuff into that branch.

That's definitely a possibility.

So a dedicated XEmacs-related person could keep such an XEmacs.
In my test branch where I remove compatibility code (not only
XEmacs, but also Emacs 21, and I'd love to ditch support for
Emacs 22 - even though I cannot do that just yet), quite some code
has changed, and I am not sure how easy it would be to keep
a compatibility branch up to date.

Is there any way to leave the compatibility code in place and not worry about it, so long as it does not interfere with your work on the current
Emacs?  (I don't know how big that interference is, I must admit.)  I
could then try to fix it up as development goes along.


here are some of the major annoyances for me:

1. posix character classes in regular expressions, thinks like [:alpha:]
   These are nice because they work well with arbitrary languages.
   Does XEmacs suppor these now?
2. The overlay API - I think XEmacs actually has a compatibility lib
   for these, is that correct?
   One of the things you could do it to figure out if I can also switch
   to the API calls overlays-in and overlays-at in that library.
   My own implementations are slightly different, and I am not sure I
   can rely on the ones in the xemacs library.
3. outline.el.  Last time  looked, XEmacs still had the horrible old
   outline.el which is pretty much impossible to program.
I do have a port, xemacs/noutline.el in the Org distribution - if you
   could get that into XEmacs, that would get rid of a major annoyance,
   including complicated installation instructions.
4. Can you make XEmacs understand mouse-3 instead of button3 ?  Or
   maybe it does understand these by now?

If you would take it on yourself to make a package for XEmacs - that
would be helpful, because then I can remove special installation
instructions for XEmacs and just tell people to get the package.

I guess you could make such a package anyway - even if it currently
cannot get into the XEmacs distribution because of license discussions.

The compromise for me would be this:

- You fix the things above.
- I leave the rest of the necessary compatibility code in
- I program any new features with whatever is available
  in Emacs 22/23 and rely on you to make it XEmacs compatible.....


- Carsten

reply via email to

[Prev in Thread] Current Thread [Next in Thread]