[Top][All Lists]

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

Re: [AUCTeX-devel] support for xemacs

From: Tassilo Horn
Subject: Re: [AUCTeX-devel] support for xemacs
Date: Thu, 23 Feb 2017 17:26:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Arash Esbati <address@hidden> writes:

>>> 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?
> There was a long discussion here[1] about using ELPA and how it could
> hold packages for Emacs in future.  My understanding is that a final
> decision is not there yet.  But I see some advantages in being on ELPA
> only.

I think the main topic of that thread is moving packages out of emacs
core into elpa.  Those packages would now have to handle backwards
compatibility issues because ELPA packages should at least be compatible
with the last emacs release whereas a core package can immediately use
bleeding-edge emacs features.

> First, it shows that packages there are more tight to Emacs core.  If
> this statement still applies:
>     AUCTeX is proceeding as a GNU project with the long-term intent of
>     merging it into Emacs.
> then this would be a right step.

Yup, but it just occurred to me that we cannot switch to elpa-only in
the middle-term future because when we have this "compat" branch, we
still need to compile releases for it.  But nothing of our build
infrastructure is part of our elpa codebase, and having separate
branches there is also not really possible AFAIK.


reply via email to

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