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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Doug Davis
This is my first stab at adding some interactive mode tagging for
python.el. I think that the navigation functions are the best place to
start; they have no use except on buffers where Python code exists and
it's expected that python-mode is enabled. (sent in my copyright
assignment paperwork today)


0001-Do-interactive-mode-tagging-for-python.el-navigation.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Doug Davis <[hidden email]> writes:

> This is my first stab at adding some interactive mode tagging for
> python.el. I think that the navigation functions are the best place to
> start; they have no use except on buffers where Python code exists and
> it's expected that python-mode is enabled. (sent in my copyright
> assignment paperwork today)

Thanks; looks good.  I've applied your patch to Emacs 28, as it seems
small enough for that, but any further patches will probably have to
wait until the assignment process has finished.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 18.02.2021 13:40, Lars Ingebrigtsen wrote:
>> This is my first stab at adding some interactive mode tagging for
>> python.el. I think that the navigation functions are the best place to
>> start; they have no use except on buffers where Python code exists and
>> it's expected that python-mode is enabled. (sent in my copyright
>> assignment paperwork today)
> Thanks; looks good.  I've applied your patch to Emacs 28, as it seems
> small enough for that, but any further patches will probably have to
> wait until the assignment process has finished.

Hi Doug, Lars,

python.el is distributed as "core" package through GNU ELPA and declared
compatibility up to Emacs 24.1.

So I don't think you can use the new 'interactive' syntax there.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Dmitry Gutov <[hidden email]> writes:

> Hi Doug, Lars,
>
> python.el is distributed as "core" package through GNU ELPA and
> declared compatibility up to Emacs 24.1.
>
> So I don't think you can use the new 'interactive' syntax there.

Sorry; I meant to check that, but I plumb forgot.  I'll revert the
change...

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Dmitry Gutov
> From: Dmitry Gutov <[hidden email]>
> Date: Thu, 18 Feb 2021 13:49:10 +0200
> Cc: [hidden email]
>
> python.el is distributed as "core" package through GNU ELPA and declared
> compatibility up to Emacs 24.1.
>
> So I don't think you can use the new 'interactive' syntax there.

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?



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 18.02.2021 16:41, Eli Zaretskii wrote:
>> python.el is distributed as "core" package through GNU ELPA and declared
>> compatibility up to Emacs 24.1.
>>
>> So I don't think you can use the new 'interactive' syntax there.
> 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?

What do you mean by "ahead"? Have a newer version of the package in
'master' and some other in ELPA?

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.

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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Cc: [hidden email], [hidden email], [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Thu, 18 Feb 2021 16:54:37 +0200
>
> On 18.02.2021 16:41, Eli Zaretskii wrote:
> >> python.el is distributed as "core" package through GNU ELPA and declared
> >> compatibility up to Emacs 24.1.
> >>
> >> So I don't think you can use the new 'interactive' syntax there.
> > 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?
>
> What do you mean by "ahead"? Have a newer version of the package in
> 'master' and some other in ELPA?

Not necessarily "newer", but one that relies on features that exist in
the Emacs version with which it is bundled.

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

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



Reply | Threaded
Open this post in threaded view
|

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

Doug Davis
In reply to this post by Dmitry Gutov
Dmitry Gutov <[hidden email]> writes:

> python.el is distributed as "core" package through GNU ELPA and
> declared compatibility up to Emacs 24.1.
>
> So I don't think you can use the new 'interactive' syntax there.

Thanks for pointing that out, I wasn't even aware python.el bundled in
emacs.git aims to be compatible outside if emacs.git. Oh well :) now I
know.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Eli Zaretskii
> Cc: [hidden email], [hidden email], [hidden email],
>  [hidden email]
> From: Dmitry Gutov <[hidden email]>
> 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.

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

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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Cc: [hidden email], [hidden email], [hidden email],
>  [hidden email]
> From: Dmitry Gutov <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Cc: [hidden email], [hidden email], [hidden email],
>  [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Thu, 18 Feb 2021 21:57:56 +0200
>
> Then this part of my first reply should be most pertinent:
>
>      Then we (someone? who?) either have to maintain both versions
>
> Emphasis on "who".

The maintainer of python.el, I presume.

And in general, if a package is both in emacs.git and in elpa.git,
there definitely should be "someone" who takes care of it.



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 18.02.2021 22:00, Eli Zaretskii wrote:

>> Cc:[hidden email],[hidden email],[hidden email],
>>   [hidden email]
>> From: Dmitry Gutov<[hidden email]>
>> Date: Thu, 18 Feb 2021 21:57:56 +0200
>>
>> Then this part of my first reply should be most pertinent:
>>
>>       Then we (someone? who?) either have to maintain both versions
>>
>> Emphasis on "who".
> The maintainer of python.el, I presume.

Which is everybody and nobody.

> And in general, if a package is both in emacs.git and in elpa.git,
> there definitely should be "someone" who takes care of it.

The current understanding of the problem is the "ELPA core" approach
(which is, let's face it, an effort-saving scheme) gives us good balance
of upside vs. effort required (maintaining several branches, doing
merges back and forth, etc).