GNU bug report logs - #40563
28.0.50; Narrow to defun in python buffer

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 40563 in the body.
You can then email your comments to 40563 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: Tomas Nordin <tomasn <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Narrow to defun in python buffer
Date: Sun, 12 Apr 2020 00:52:13 +0200

Hello Buglist

emacs Q

Find file class.py with this content

----------------------------------8<----------------------------------
"""Try narrow to defun on class"""


class A():

    def a1(self):
        pass

    def a2(self):
        pass


class B():

    def b1(self):
        pass

    def b2(self):
        pass
---------------------------------->8----------------------------------

Move point to bol on class A
C-x n d

result:
----------------------------------8<----------------------------------
lass A():

    def a1(self):
        pass

    def a2(self):
        pass
---------------------------------->8----------------------------------

notice the 'c' is gone

C-x n w

Move point to bol on class B

C-x n d

result:
----------------------------------8<----------------------------------
    def b2(self):
        pass
---------------------------------->8----------------------------------

I then noticed that placing point just below the class definition and
then narrow works as expected. But I think the recipe way should work as
well. And even if not, this behavior is confusing.

Best regards
--
Tomas

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2020-04-01 built on fliptop
Repository revision: 1276c8e10b000b571a12227ebe9216cc6305ef7f
Repository branch: tomnor
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Dired-Hide-Details mode enabled in current buffer

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS PDUMPER LCMS2
GMP

Important settings:
  value of $LC_TIME: sv_SE.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  dired-hide-details-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date subr-x seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired
dired-loaddefs tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 44956 6005)
 (symbols 48 5991 1)
 (strings 32 15464 1586)
 (string-bytes 1 508063)
 (vectors 16 9265)
 (vector-slots 8 124796 8898)
 (floats 8 19 43)
 (intervals 56 325 4)
 (buffers 1000 12))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Mon, 26 Oct 2020 14:57:15 +0100

Tomas Nordin <tomasn <at> posteo.net> writes:

> I then noticed that placing point just below the class definition and
> then narrow works as expected. But I think the recipe way should work as
> well. And even if not, this behavior is confusing.

This bug is still present on the trunk.

The problem is most easily reproduced by calling the

  (python-nav--beginning-of-defun)

function directly.  If point is on the first line, then this function
won't do the right thing:

def a1(self):
    pass

Because it starts off checking whether it is, indeed, on the first line
before trying to get to the start of the first line in the function.

This seems like such a basic problem that I wondered whether it's a
newly introduced bug, but it's been there for...  at least a decade,
apparently?

Doesn't anybody use python-mode?

It looks easy enough to fix, but I'm just wondering whether there's
something obvious here I'm not seeing.

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

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

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Tue, 01 Dec 2020 22:01:42 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Tomas Nordin <tomasn <at> posteo.net> writes:
>
>> I then noticed that placing point just below the class definition and
>> then narrow works as expected. But I think the recipe way should work as
>> well. And even if not, this behavior is confusing.
>
> This bug is still present on the trunk.
>
> The problem is most easily reproduced by calling the
>
>   (python-nav--beginning-of-defun)
>
> function directly.  If point is on the first line, then this function
> won't do the right thing:
>
> def a1(self):
>     pass
>

It does the right thing here (still on the same build) when point is at
column > 4, and the wrong thing when at 4 or less. Indentation?

--
Tomas

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

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Tue, 01 Dec 2020 22:05:14 +0100

Tomas Nordin <tomasn <at> posteo.net> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Tomas Nordin <tomasn <at> posteo.net> writes:
>>
>>> I then noticed that placing point just below the class definition and
>>> then narrow works as expected. But I think the recipe way should work as
>>> well. And even if not, this behavior is confusing.
>>
>> This bug is still present on the trunk.
>>
>> The problem is most easily reproduced by calling the
>>
>>   (python-nav--beginning-of-defun)
>>
>> function directly.  If point is on the first line, then this function
>> won't do the right thing:
>>
>> def a1(self):
>>     pass
>>
>
> It does the right thing here (still on the same build) when point is at
> column > 4, and the wrong thing when at 4 or less. Indentation?

Or I said wrong, now my version is 28.0.50 2020-06-07.

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

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Fri, 4 Dec 2020 08:48:01 +0100

On 01.12.20 22:05, Tomas Nordin wrote:
> Tomas Nordin <tomasn <at> posteo.net> writes:
>
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>>> Tomas Nordin <tomasn <at> posteo.net> writes:
>>>
>>>> I then noticed that placing point just below the class definition and
>>>> then narrow works as expected. But I think the recipe way should work as
>>>> well. And even if not, this behavior is confusing.
>>> This bug is still present on the trunk.
>>>
>>> The problem is most easily reproduced by calling the
>>>
>>>    (python-nav--beginning-of-defun)
>>>
>>> function directly.  If point is on the first line, then this function
>>> won't do the right thing:
>>>
>>> def a1(self):
>>>      pass
>>>
>> It does the right thing here (still on the same build) when point is at
>> column > 4, and the wrong thing when at 4 or less. Indentation?
> Or I said wrong, now my version is 28.0.50 2020-06-07.
>
>

May reproduce this with

GNU Emacs 28.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.14.5, 
cairo version 1.14.0) of 2020-11-19

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

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Sun, 13 Dec 2020 14:32:38 +0100

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

Hello

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Tomas Nordin <tomasn <at> posteo.net> writes:
>
>> I then noticed that placing point just below the class definition and
>> then narrow works as expected. But I think the recipe way should work as
>> well. And even if not, this behavior is confusing.
>
> This bug is still present on the trunk.
>
> The problem is most easily reproduced by calling the
>
>   (python-nav--beginning-of-defun)
>
> function directly.  If point is on the first line, then this function
> won't do the right thing:
>
> def a1(self):
>     pass

Attached is a patch that fix the problems described in this report. The
change of variable name 'beg-indentation' to 'body-indentation' is not
part of the fix, but something I did during study making it easier for
me to understand the meaning of it. Feel free to disagree on that
change. The naming beg-indentation does not re-occur in python.el

The patch mean to say it might be necessary to move forward on the line
before search if point start off at the beginning of the defun, to allow
re-search-backward to succeed on the intended place.

The patch fixes this report, but it doesn't allow narrowing nested
python defuns (like a def in a class). For that I think it is necassary
to look at narrow-to-defun. I intend to suggest something about that in
another report.

What do you think?

Best regards
--
Tomas

[beginning-of-defun.patch (text/x-diff, inline)]

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index e9c3b3986a..32ffc5a9d6 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -1404,7 +1404,7 @@ python-nav--beginning-of-defun
          (line-beg-pos (line-beginning-position))
          (line-content-start (+ line-beg-pos (current-indentation)))
          (pos (point-marker))
-         (beg-indentation
+         (body-indentation
           (and (> arg 0)
                (save-excursion
                  (while (and
@@ -1415,9 +1415,16 @@ python-nav--beginning-of-defun
                      0))))
          (found
           (progn
-            (when (and (< arg 0)
-                       (python-info-looking-at-beginning-of-defun))
+            (when (and (python-info-looking-at-beginning-of-defun)
+                       (or (< arg 0)
+                           ;; If looking at beginning of defun, and if
+                           ;; pos is > line-content-start, ensure a
+                           ;; backward re search match this defun by
+                           ;; going to end of line before calling
+                           ;; re-search-fn bug#40563
+                           (and (> arg 0) (> pos line-content-start))))
               (end-of-line 1))
+
             (while (and (funcall re-search-fn
                                  python-nav-beginning-of-defun-regexp nil t)
                         (or (python-syntax-context-type)
@@ -1425,7 +1432,7 @@ python-nav--beginning-of-defun
                             ;; backwards by checking indentation.
                             (and (> arg 0)
                                  (not (= (current-indentation) 0))
-                                 (>= (current-indentation) beg-indentation)))))
+                                 (>= (current-indentation) body-indentation)))))
             (and (python-info-looking-at-beginning-of-defun)
                  (or (not (= (line-number-at-pos pos)
                              (line-number-at-pos)))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Mon, 14 Dec 2020 17:00:30 +0100

Tomas Nordin <tomasn <at> posteo.net> writes:

> The patch fixes this report, but it doesn't allow narrowing nested
> python defuns (like a def in a class). For that I think it is necassary
> to look at narrow-to-defun. I intend to suggest something about that in
> another report.
>
> What do you think?

Looks good to me (and it fixes the bug described in this bug report), so
I've now applied the patch to Emacs 28.

This change was small enough to apply without assigning copyright to the
FSF, but for future patches you want to submit, it might make sense to
get the paperwork started now, so that subsequent patches can be applied
speedily. Would you be willing to sign such paperwork?

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

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

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Mon, 14 Dec 2020 20:38:29 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Tomas Nordin <tomasn <at> posteo.net> writes:
>
>> The patch fixes this report, but it doesn't allow narrowing nested
>> python defuns (like a def in a class). For that I think it is necassary
>> to look at narrow-to-defun. I intend to suggest something about that in
>> another report.
>>
>> What do you think?
>
> Looks good to me (and it fixes the bug described in this bug report), so
> I've now applied the patch to Emacs 28.

Thanks

>
> This change was small enough to apply without assigning copyright to
the
> FSF, but for future patches you want to submit, it might make sense to
> get the paperwork started now, so that subsequent patches can be applied
> speedily. Would you be willing to sign such paperwork?

Yes, surely. Please paper me.

--
Tomas

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Mon, 14 Dec 2020 21:03:05 +0100

Tomas Nordin <tomasn <at> posteo.net> writes:

>> This change was small enough to apply without assigning copyright to
> the
>> FSF, but for future patches you want to submit, it might make sense to
>> get the paperwork started now, so that subsequent patches can be applied
>> speedily. Would you be willing to sign such paperwork?
>
> Yes, surely. Please paper me.

Great; here's the form to get started:

----

Please email the following information to assign <at> gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]

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

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40563 <at> debbugs.gnu.org
Subject: Re: bug#40563: 28.0.50; Narrow to defun in python buffer
Date: Mon, 14 Dec 2020 23:18:55 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Tomas Nordin <tomasn <at> posteo.net> writes:
>
>>> This change was small enough to apply without assigning copyright to
>> the
>>> FSF, but for future patches you want to submit, it might make sense to
>>> get the paperwork started now, so that subsequent patches can be applied
>>> speedily. Would you be willing to sign such paperwork?
>>
>> Yes, surely. Please paper me.
>
> Great; here's the form to get started:

Sent

Previous Next

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