GNU bug report logs - #29608
python.el movement functions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29608 in the body.
You can then email your comments to 29608 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex Branham <alex.branham <at> gmail.com>
To: "" <bug-gnu-emacs <at> gnu.org>
Subject: python.el movement functions
Date: Thu, 07 Dec 2017 15:08:30 -0600

Python movement statements do not always result in the behavior I'd expect. Consider this python file (with (|) representing point):

(|)for i in [1, 2, 3]:
    print(i)

I'd expect M-x python-nav-forward-statement to result in

for i in [1, 2, 3]:
    print(i)
(|)

but instead you wind up with

for i in [1, 2, 3]:
    (|)print(i)

and python-nav-forward-block (bound to M-e) is even worse. It results in point not moving at all:

(|)for i in [1, 2, 3]:
    print(i)

Message #8 received at 29608 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Alex Branham <alex.branham <at> gmail.com>
Cc: 29608 <at> debbugs.gnu.org
Subject: Re: bug#29608: python.el movement functions
Date: Fri, 08 Dec 2017 12:56:44 -0500

Alex Branham wrote:

> Python movement statements do not always result in the behavior I'd
> expect. Consider this python file (with (|) representing point):
>
> (|)for i in [1, 2, 3]:
>     print(i)
>
> I'd expect M-x python-nav-forward-statement to result in
>
> for i in [1, 2, 3]:
>     print(i)
> (|)
>
> but instead you wind up with
>
> for i in [1, 2, 3]:
>     (|)print(i)

The actual result seems reasonable to me?

> and python-nav-forward-block (bound to M-e) is even worse. It results
> in point not moving at all:
>
> (|)for i in [1, 2, 3]:
>     print(i)

It seems that you disagree with python.el's definition of "statement" and
"block". Eg the block definition seems to be:

(defconst python-rx-constituents
  `((block-start          . ,(rx symbol-start
                                 (or "def" "class" "if" "elif" "else" "try"
                                     "except" "finally" "for" "while" "with"
                                     ;; Python 3.5+ PEP492
                                     (and "async" (+ space)
                                          (or "def" "for" "with")))
                                 symbol-end))

Message #11 received at 29608 <at> debbugs.gnu.org (full text, mbox):

From: Alex Branham <alex.branham <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 29608 <at> debbugs.gnu.org
Subject: Re: bug#29608: python.el movement functions
Date: Fri, 08 Dec 2017 15:37:15 -0600

On Fri 08 Dec 2017 at 17:56, Glenn Morris <rgm <at> gnu.org> wrote:

> Alex Branham wrote:
>
>> Python movement statements do not always result in the behavior I'd
>> expect. Consider this python file (with (|) representing point):
>>
>> (|)for i in [1, 2, 3]:
>>     print(i)
>>
>> I'd expect M-x python-nav-forward-statement to result in
>>
>> for i in [1, 2, 3]:
>>     print(i)
>> (|)
>>
>> but instead you wind up with
>>
>> for i in [1, 2, 3]:
>>     (|)print(i)
>
> The actual result seems reasonable to me?

I'd argue that a "statement" should contain a whole logically valid statement, but I see your point.

>
>> and python-nav-forward-block (bound to M-e) is even worse. It results
>> in point not moving at all:
>>
>> (|)for i in [1, 2, 3]:
>>     print(i)
>
> It seems that you disagree with python.el's definition of "statement" and
> "block". Eg the block definition seems to be:
>
> (defconst python-rx-constituents
>   `((block-start          . ,(rx symbol-start
>                                  (or "def" "class" "if" "elif" "else" "try"
>                                      "except" "finally" "for" "while" "with"
>                                      ;; Python 3.5+ PEP492
>                                      (and "async" (+ space)
>                                           (or "def" "for" "with")))
>                                  symbol-end))

Shouldn't python-nav-forward-block actually navigate forward, though?
And if we're on the last block in the buffer, just leave point at the
end?

This might be off-topic, but what I'm trying to do is to write a function that I can bind so that C-<return> acts like it does in ESS where you can continue to hit it and it will eventually evaluate everything in the buffer. Here's what I have so far:

(defun python-shell-send-region-or-statement ()
  "Send the current region to the inferior python process if there is an active one, otherwise the current line."
  (interactive)
  (if (use-region-p)
      (python-shell-send-region (region-beginning) (region-end))
    (python-shell-send-statement)))

(defun python-shell-send-statement ()
  "Send the current line to the inferior python process for evaluation."
  (interactive)
  (save-excursion
    (let ((end (python-nav-end-of-statement))
          (beginning (python-nav-beginning-of-statement)))
      (python-shell-send-region beginning end))))

(defun python-shell-send-region-or-statement-and-step ()
  "Call `python-shell-send-region-or-statement' and then `python-nav-forward-statement'."
  (interactive)
  (python-shell-send-region-or-statement)
  (python-nav-forward-statement))

Message #14 received at 29608 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alex Branham <alex.branham <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 29608 <at> debbugs.gnu.org
Subject: Re: bug#29608: python.el movement functions
Date: Sat, 26 Jun 2021 16:13:12 +0200

Alex Branham <alex.branham <at> gmail.com> writes:

> Shouldn't python-nav-forward-block actually navigate forward, though?
> And if we're on the last block in the buffer, just leave point at the
> end?

Well, the `M-e' doc string says "Move forward to next block of code.",
so if there is no next code block, then there's nothing to move to.  So
I think it's working as intended, I guess?  It does seem slightly
eccentric -- I'd also expect it to move to the end of the current block,
but then there's `python-nav-end-of-block' for that.

But I don't think there's anything to fix here, so I'm closing this bug
report.  

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.