[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.
Bye,
Tassilo
- [AUCTeX-devel] support for xemacs, (continued)
- [AUCTeX-devel] support for xemacs, Ikumi Keita, 2017/02/19
- Re: [AUCTeX-devel] support for xemacs, Arash Esbati, 2017/02/19
- Re: [AUCTeX-devel] support for xemacs, Uwe Brauer, 2017/02/19
- Re: [AUCTeX-devel] support for xemacs, Tassilo Horn, 2017/02/22
- Re: [AUCTeX-devel] support for xemacs, Mosè Giordano, 2017/02/22
- Re: [AUCTeX-devel] support for xemacs, Tassilo Horn, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Ikumi Keita, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Uwe Brauer, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Mosè Giordano, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Arash Esbati, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs,
Tassilo Horn <=
- Re: [AUCTeX-devel] support for xemacs, Arash Esbati, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Uwe Brauer, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Mosè Giordano, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Ikumi Keita, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Mosè Giordano, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Uwe Brauer, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Uwe Brauer, 2017/02/23
- Re: [AUCTeX-devel] support for xemacs, Tassilo Horn, 2017/02/23
Re: [AUCTeX-devel] A simple patch displaying compilation time, Arash Esbati, 2017/02/19