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

[Dmitry Gutov]

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.