GNU bug report logs - #77941
[PATCH] Fix Python block end predicates

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#77941: closed ([PATCH] Fix Python block end predicates)
Date: Sat, 26 Apr 2025 11:24:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 26 Apr 2025 14:23:40 +0300
with message-id <86h62bupxf.fsf <at> gnu.org>
and subject line Re: bug#77941: [PATCH] Fix Python block end predicates
has caused the debbugs.gnu.org bug report #77941,
regarding [PATCH] Fix Python block end predicates
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
77941: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77941
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: kobarity <kobarity <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Fix Python block end predicates
Date: Sun, 20 Apr 2025 23:56:29 +0900

[Message part 3 (text/plain, inline)]

In the process of looking into #77620, I noticed bugs in the
end-of-block detection functions in python.el.  If there is a comment
on the last line of the block, `python-info-statement-ends-block-p'
and `python-info-end-of-block-p' will not work correctly. 

Try the following Python code.

def func():
    return 0  # Comment

When the point is located after "0" of the return statement, both
`python-info-statement-ends-block-p' and `python-info-end-of-block-p'
return nil.  If there is no comment on the line, they return t as
expected.

This bug affects `python-nav-forward-sexp'.  In the above example, if
the point is located at the beginning of "def func()" line,
(python-nav-forward-sexp) moves the point to after "0".  This is the
expected behavior.

However, if we execute (python-nav-forward-sexp -1) there, it moves
the point to "0". This is not the expected behavior.  If there is no
comment, it moves the point to the beginning of "def func()" line.

Attached is a patch that fixes this problem.

--
In GNU Emacs 31.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2025-01-01 built on ubuntu2404
Repository revision: 78bc5949db489b143f7424540d6cc56fc529c9ea
Repository branch: master
System Description: Ubuntu 24.04.2 LTS

Configured using:
 'configure --with-pgtk --with-native-compilation --with-tree-sitter'

[0001-Fix-Python-block-end-predicates.patch (application/octet-stream, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: 77941-done <at> debbugs.gnu.org
Subject: Re: bug#77941: [PATCH] Fix Python block end predicates
Date: Sat, 26 Apr 2025 14:23:40 +0300

> Date: Sun, 20 Apr 2025 23:56:29 +0900
> From: kobarity <kobarity <at> gmail.com>
> 
> In the process of looking into #77620, I noticed bugs in the
> end-of-block detection functions in python.el.  If there is a comment
> on the last line of the block, `python-info-statement-ends-block-p'
> and `python-info-end-of-block-p' will not work correctly. 
> 
> Try the following Python code.
> 
> def func():
>     return 0  # Comment
> 
> When the point is located after "0" of the return statement, both
> `python-info-statement-ends-block-p' and `python-info-end-of-block-p'
> return nil.  If there is no comment on the line, they return t as
> expected.
> 
> This bug affects `python-nav-forward-sexp'.  In the above example, if
> the point is located at the beginning of "def func()" line,
> (python-nav-forward-sexp) moves the point to after "0".  This is the
> expected behavior.
> 
> However, if we execute (python-nav-forward-sexp -1) there, it moves
> the point to "0". This is not the expected behavior.  If there is no
> comment, it moves the point to the beginning of "def func()" line.
> 
> Attached is a patch that fixes this problem.

Thanks, installed, and closing the bug.

Previous Next

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