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

[Dmitry Gutov <dgutov@yandex.ru>]

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.