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

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

[Doug Davis]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

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)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Do-interactive-mode-tagging-for-python.el-navigation.patch --]
[-- Type: text/x-patch, Size: 6676 bytes --]

From 945fa0b60174b168c7d928b36844ebe6c73bf253 Mon Sep 17 00:00:00 2001
From: Doug Davis <ddavis@ddavis.io>
Date: Wed, 17 Feb 2021 23:37:00 -0500
Subject: [PATCH] Do interactive mode tagging for python.el navigation
 functions.

* lisp/progmodes/python.el (navigation functions): add python-mode to
`interactive' declarations for all interactive functions.
---
 lisp/progmodes/python.el | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index afb96974b1..7506043a19 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -1506,7 +1506,7 @@ python-nav-beginning-of-defun
 (defun python-nav-end-of-defun ()
   "Move point to the end of def or class.
 Returns nil if point is not in a def or class."
-  (interactive)
+  (interactive nil python-mode)
   (let ((beg-defun-indent)
         (beg-pos (point)))
     (when (or (python-info-looking-at-beginning-of-defun)
@@ -1577,19 +1577,19 @@ python-nav-backward-defun
   "Navigate to closer defun backward ARG times.
 Unlikely `python-nav-beginning-of-defun' this doesn't care about
 nested definitions."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (python-nav--forward-defun (- (or arg 1))))
 
 (defun python-nav-forward-defun (&optional arg)
   "Navigate to closer defun forward ARG times.
 Unlikely `python-nav-beginning-of-defun' this doesn't care about
 nested definitions."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (python-nav--forward-defun (or arg 1)))
 
 (defun python-nav-beginning-of-statement ()
   "Move to start of current statement."
-  (interactive "^")
+  (interactive "^" python-mode)
   (forward-line 0)
   (let* ((ppss (syntax-ppss))
          (context-point
@@ -1613,7 +1613,7 @@ python-nav-end-of-statement
 Optional argument NOEND is internal and makes the logic to not
 jump to the end of line when moving forward searching for the end
 of the statement."
-  (interactive "^")
+  (interactive "^" python-mode)
   (let (string-start bs-pos (last-string-end 0))
     (while (and (or noend (goto-char (line-end-position)))
                 (not (eobp))
@@ -1654,7 +1654,7 @@ python-nav-end-of-statement
 (defun python-nav-backward-statement (&optional arg)
   "Move backward to previous statement.
 With ARG, repeat.  See `python-nav-forward-statement'."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (python-nav-forward-statement (- arg)))
 
@@ -1662,7 +1662,7 @@ python-nav-forward-statement
   "Move forward to next statement.
 With ARG, repeat.  With negative argument, move ARG times
 backward to previous statement."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (while (> arg 0)
     (python-nav-end-of-statement)
@@ -1677,7 +1677,7 @@ python-nav-forward-statement
 
 (defun python-nav-beginning-of-block ()
   "Move to start of current block."
-  (interactive "^")
+  (interactive "^" python-mode)
   (let ((starting-pos (point)))
     (if (progn
           (python-nav-beginning-of-statement)
@@ -1701,7 +1701,7 @@ python-nav-beginning-of-block
 
 (defun python-nav-end-of-block ()
   "Move to end of current block."
-  (interactive "^")
+  (interactive "^" python-mode)
   (when (python-nav-beginning-of-block)
     (let ((block-indentation (current-indentation)))
       (python-nav-end-of-statement)
@@ -1717,7 +1717,7 @@ python-nav-end-of-block
 (defun python-nav-backward-block (&optional arg)
   "Move backward to previous block of code.
 With ARG, repeat.  See `python-nav-forward-block'."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (python-nav-forward-block (- arg)))
 
@@ -1725,7 +1725,7 @@ python-nav-forward-block
   "Move forward to next block of code.
 With ARG, repeat.  With negative argument, move ARG times
 backward to previous block."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (let ((block-start-regexp
          (python-rx line-start (* whitespace) block-start))
@@ -1878,7 +1878,7 @@ python-nav-forward-sexp
 argument SKIP-PARENS-P force sexp motion to ignore parenthesized
 expressions when looking at them in either direction (forced to t
 in interactive calls)."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   ;; Do not follow parens on interactive calls.  This hack to detect
   ;; if the function was called interactively copes with the way
@@ -1912,7 +1912,7 @@ python-nav-backward-sexp
 argument SKIP-PARENS-P force sexp motion to ignore parenthesized
 expressions when looking at them in either direction (forced to t
 in interactive calls)."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (python-nav-forward-sexp (- arg) safe skip-parens-p))
 
@@ -1922,7 +1922,7 @@ python-nav-forward-sexp-safe
 backward N times.  With optional argument SKIP-PARENS-P force
 sexp motion to ignore parenthesized expressions when looking at
 them in either direction (forced to t in interactive calls)."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (python-nav-forward-sexp arg t skip-parens-p))
 
 (defun python-nav-backward-sexp-safe (&optional arg skip-parens-p)
@@ -1931,7 +1931,7 @@ python-nav-backward-sexp-safe
 forward N times.  With optional argument SKIP-PARENS-P force sexp
 motion to ignore parenthesized expressions when looking at them in
 either direction (forced to t in interactive calls)."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (python-nav-backward-sexp arg t skip-parens-p))
 
 (defun python-nav--up-list (&optional dir)
@@ -1977,7 +1977,7 @@ python-nav-up-list
 With ARG, do this that many times.
 A negative argument means move backward but still to a less deep spot.
 This command assumes point is not in a string or comment."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (while (> arg 0)
     (python-nav--up-list 1)
@@ -1991,7 +1991,7 @@ python-nav-backward-up-list
 With ARG, do this that many times.
 A negative argument means move forward but still to a less deep spot.
 This command assumes point is not in a string or comment."
-  (interactive "^p")
+  (interactive "^p" python-mode)
   (or arg (setq arg 1))
   (python-nav-up-list (- arg)))
 
@@ -1999,7 +1999,7 @@ python-nav-if-name-main
   "Move point at the beginning the __main__ block.
 When \"if __name__ == \\='__main__\\=':\" is found returns its
 position, else returns nil."
-  (interactive)
+  (interactive nil python-mode)
   (let ((point (point))
         (found (catch 'found
                  (goto-char (point-min))
-- 
2.30.1

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

[Lars Ingebrigtsen]

Doug Davis <ddavis@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

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.

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 18 Feb 2021 13:49:10 +0200
> Cc: 46610@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?

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.

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

[Eli Zaretskii]

> Cc: ddavis@ddavis.io, larsi@gnus.org, 46610@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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?

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

[Dmitry Gutov]

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.

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

[Doug Davis]

Dmitry Gutov <dgutov@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.

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

[Eli Zaretskii]

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

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

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.

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

[Eli Zaretskii]

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

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

[Dmitry Gutov]

On 18.02.2021 21:47, 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 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".

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

[Eli Zaretskii]

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

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

[Dmitry Gutov]

On 18.02.2021 22:00, 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 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).