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

[Carsten Dominik <carsten.dominik@gmail.com>]

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 <carsten.dominik@gmail.com> 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
>> limited.
>
> 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.

Well,

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

Cheers

- Carsten