|
From: | Dmitry Gutov |
Subject: | bug#46610: Interactive mode tagging for python.el navigation functions |
Date: | Thu, 18 Feb 2021 19:54:06 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 18.02.2021 19:25, Eli Zaretskii wrote:
Cc: ddavis@ddavis.io, larsi@gnus.org, 46610@debbugs.gnu.org, monnier@iro.umontreal.ca From: Dmitry Gutov <dgutov@yandex.ru> Date: Thu, 18 Feb 2021 17:37:37 +0200Not necessarily "newer", but one that relies on features that exist in the Emacs version with which it is bundled.This can be done with either maintaining a separate version of python.el somewhere in a different repo, or with version checks inside the main file, compatibility aliases, etc. Neither seems warranted for the feature in question, since we have a backward-compatible syntax as well.My question is more of the conceptual kind, not necessarily about this specific change. Your original response was also about the principle, AFAIU.
I guess I'm not sure what you are asking about at this point, so I'm trying to cover all the bases: yes, python.el is allowed to incorporate support for some new features from Emacs 28, as long as they are backward-compatible, or gated behind a version check.
Speaking about "conceptual" replies, I don't really care for python.el personally, but I've been thinking of making ruby-mode.el an "ELPA core" package too.
Then we (someone? who?) either have to maintain both version, or accept that ELPA and all users of Emacs 24-27 won't get any subsequent updates to python.el, including support for newer Python syntax, etc.I don't think I understand why. We are talking about changing python.el on master, which will be released with Emacs 28, in some not-too-close future. What does that have to do with users of older Emacsen receiving updates to python.el? I guess I'm confused here.Emacs 27 users can install the most recent version of python.el from GNU ELPA. This is generally a good thing.Sure, but if the ELPA version doesn't have these changes, there's no problem, right?
The problem might be users missing some features that had been added to python.el in emacs.git master in the meantime.
Either approach can work in ELPA, but our "ELPA core" scheme aims to make new features available to as many users as feasible, while limiting the extra support effort required.The new features on master will be available only when Emacs 28 is released, until then they cannot possibly do any harm to anyone. Right?I meant the "new features" of python.el (not of Emacs 28 core) and of other "ELPA core" packages.Those new features are not merged to python.el in master branch of the Emacs repository?
emacs.git master is the "upstream" for python.el, so "new features" and "features merged to python.el in master branch of the Emacs repository" describe the same thing.
If they are, then users of older Emacsen can have them from ELPA, while those who use the development version will have them from master. Right?
That's how it works, yes.
[Prev in Thread] | Current Thread | [Next in Thread] |