GNU bug report logs -
#46610
Interactive mode tagging for python.el navigation functions
Previous Next
Reported by: Doug Davis <ddavis <at> ddavis.io>
Date: Thu, 18 Feb 2021 04:47:02 UTC
Severity: normal
Tags: fixed
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46610 in the body.
You can then email your comments to 46610 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 04:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Doug Davis <ddavis <at> ddavis.io>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 18 Feb 2021 04:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 11:41:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 46610 <at> debbugs.gnu.org (full text, mbox):
Doug Davis <ddavis <at> ddavis.io> 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
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 18 Feb 2021 11:41:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
46610 <at> debbugs.gnu.org and Doug Davis <ddavis <at> ddavis.io>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 18 Feb 2021 11:41:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 11:50:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 46610 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 11:53:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 46610 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 14:42:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 46610 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 18 Feb 2021 13:49:10 +0200
> Cc: 46610 <at> debbugs.gnu.org
>
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 14:55:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 46610 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 15:08:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 46610 <at> debbugs.gnu.org (full text, mbox):
> Cc: ddavis <at> ddavis.io, larsi <at> gnus.org, 46610 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 15:38:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 46610 <at> debbugs.gnu.org (full text, mbox):
On 18.02.2021 17:07, Eli Zaretskii wrote:
>>>> 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.
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.
>> 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.
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 15:52:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 46610 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 17:26:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 46610 <at> debbugs.gnu.org (full text, mbox):
> Cc: ddavis <at> ddavis.io, larsi <at> gnus.org, 46610 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> 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.
> >> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 17:55:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 46610 <at> debbugs.gnu.org (full text, mbox):
On 18.02.2021 19:25, Eli Zaretskii wrote:
>> Cc: ddavis <at> ddavis.io, larsi <at> gnus.org, 46610 <at> debbugs.gnu.org,
>> monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 19:48:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 46610 <at> debbugs.gnu.org (full text, mbox):
> Cc: ddavis <at> ddavis.io, larsi <at> gnus.org, 46610 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 19:59:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 46610 <at> debbugs.gnu.org (full text, mbox):
On 18.02.2021 21:47, Eli Zaretskii wrote:
>> Cc: ddavis <at> ddavis.io, larsi <at> gnus.org, 46610 <at> debbugs.gnu.org,
>> monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> 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:
Very good.
>> 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.
Then this part of my first reply should be most pertinent:
Then we (someone? who?) either have to maintain both versions
Emphasis on "who".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 20:02:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 46610 <at> debbugs.gnu.org (full text, mbox):
> Cc: ddavis <at> ddavis.io, larsi <at> gnus.org, 46610 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46610; Package
emacs.
(Thu, 18 Feb 2021 20:06:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 46610 <at> debbugs.gnu.org (full text, mbox):
On 18.02.2021 22:00, Eli Zaretskii wrote:
>> Cc:ddavis <at> ddavis.io,larsi <at> gnus.org,46610 <at> debbugs.gnu.org,
>> monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>> 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).
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 19 Mar 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 28 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.