[Top][All Lists]

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

Re: [AUCTeX-devel] support for xemacs

From: Mosè Giordano
Subject: Re: [AUCTeX-devel] support for xemacs
Date: Wed, 22 Feb 2017 19:50:44 +0100

Hello everybody,

2017-02-22 19:32 GMT+01:00 Tassilo Horn <address@hidden>:
> Arash Esbati <address@hidden> writes:
> Hi all,
>> known compat-issues with some `if' constructs, release a new AUCTeX
>> and mark it as the last one which supports XEmacs and focus on
>> supporting Emacs.  This might sound harsh, but the future of XEmacs
>> seems to be uncertain.  If in some years XEmacs is alive and kicking
>> again, we could see how we can support it again and make incompatible
>> functions work again.
>> But for the time being, I don't want to do without many features
>> provided by Emacs and not by XEmacs (see above).  The same thing
>> applies to older versions of Emacs: I think we should support
>> Emacs>=24 as we are trying to move users towards ELPA.
> That's pretty much my perspective, and that's the way Gnus and Org went,
> too.

I completely with both of you.

> So doing another release anytime soon where the compat issues Ikumi
> found are fixed would be a good thing.  Maybe an even better plan was to
> release 11.91 and 12.0 identically in parallel where 11.91 would be the
> last XEmacs (and Emacs 21/22/23?) compatible release and 12.0 the normal
> (recent Emacsen) release and to create an compat branch.  Then we could
> have 11.91.x releases with just compat fixes for XEmacs/old Emacsen but
> no new features, and with version 12+ we could start caring about
> compatibility only for the last few Emacs releases.

Do you mean that the branch would be for fixes only, so that in master
we can completely remove hundreds of lines of compatibility code?  If
so, I'm all for this option.

> I'm also thinking about maybe closing down our own git repository and
> move over to the emacs-elpa repository and do only ELPA releases (after
> all, you can do a system-wide installation of an ELPA package which is
> the main cause for the standalone release).  Right now, the situation is
> not overly problematic but there were times where Stefan Monnier fixed
> tons of (mostly byte compilation) issues in auctex on emacs-elpa
> (thanks!) and I really had no joy in cherry-picking those changes to our
> own repository given that in auctex.git several files are generated
> during compilation but are checked in in emacs-elpa.

I'm not completely convinced by this (but I didn't have to wrestle
with conflicting merges ;-).  What would be other advantages?


reply via email to

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