bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#46610: Interactive mode tagging for python.el navigation functions


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 +0200

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





reply via email to

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