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

[Eli Zaretskii <eliz@gnu.org>]

> 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 19:54:06 +0200
> 
> > 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

Let me repeat my original question:

> So packages on ELPA are allowed to be ahead of those in core, but not
> vice versa?  Is that really the intent that we allow them to diverge,
> but only in one direction?

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

If python.el in emacs.git is allowed to be different from that in
elpa.git (and AFAIU we already allow that), then there should be no
need for any compatibility shims in the version that is in emacs.git.

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

We don't yet understand/agree what does "ELPA core" mean, so I don't
think we can usefully discuss that here and now.

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

Those should be installed in elpa.git as well.