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.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29608
; Package
emacs
.
(Thu, 07 Dec 2017 21:09:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alex Branham <alex.branham <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 07 Dec 2017 21:09:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29608
; Package
emacs
.
(Fri, 08 Dec 2017 17:57:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 29608 <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29608
; Package
emacs
.
(Fri, 08 Dec 2017 21:38:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 29608 <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29608
; Package
emacs
.
(Sat, 26 Jun 2021 14:14:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 29608 <at> debbugs.gnu.org (full text, mbox):
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
bug closed, send any further explanations to
29608 <at> debbugs.gnu.org and Alex Branham <alex.branham <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 26 Jun 2021 14:14:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 25 Jul 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 273 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.