GNU bug report logs - #72759
31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil

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 72759 in the body.
You can then email your comments to 72759 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: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set
 to nil
Date: Thu, 22 Aug 2024 12:07:38 +0200

1. emacs -Q
2. (setq open-paren-in-column-0-is-defun-start nil)
3. Insert " (foo"
4. M-x flymake-mode
5. Emacs hangs

I can reproduce this with Emacs 29 and later.


Best,

Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50;
 Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 13:56:28 +0300

> Date: Thu, 22 Aug 2024 12:07:38 +0200
> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> 1. emacs -Q
> 2. (setq open-paren-in-column-0-is-defun-start nil)
> 3. Insert " (foo"
> 4. M-x flymake-mode
> 5. Emacs hangs
> 
> I can reproduce this with Emacs 29 and later.

Thanks.  Could you show the Lisp backtrace from the hang (assuming it
hangs in Lisp code)?

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 13:31:16 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 22 Aug 2024 12:07:38 +0200
>> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> 1. emacs -Q
>> 2. (setq open-paren-in-column-0-is-defun-start nil)
>> 3. Insert " (foo"
>> 4. M-x flymake-mode
>> 5. Emacs hangs
>> 
>> I can reproduce this with Emacs 29 and later.
>
> Thanks.  Could you show the Lisp backtrace from the hang (assuming it
> hangs in Lisp code)?

Sure, see the backtrace below.  It appears that the hang is in
checkdoc-next-docstring, namely this loop...

--8<---------------cut here---------------start------------->8---
(while (and (not (setq found (checkdoc--next-docstring)))
                (beginning-of-defun -1)))
--8<---------------cut here---------------end--------------->8---

...never terminates, because beginning-of-defun behaves differently with
open-paren-in-column-0-is-defun-start set to nil.


Here's an example backtrace:

--8<---------------cut here---------------start------------->8---
Debugger entered--beginning evaluation of function call form:
* (save-current-buffer (set-buffer buffer) (set-syntax-table table))
  (unwind-protect (progn (set-syntax-table (or syntax-ppss-table (syntax-table))) (let* ((cell (syntax-ppss--data)) (ppss-last (car cell)) (ppss-cache (cdr cell)) (old-ppss (cdr ppss-last)) (old-pos (car ppss-last)) (ppss nil) (pt-min (point-min))) (if (and old-pos (> old-pos pos)) (setq old-pos nil)) (condition-case nil (if (and old-pos (< (- pos old-pos) (let ... ...))) (progn (syntax-ppss--update-stats 0 old-pos pos) (parse-partial-sexp old-pos pos nil nil old-ppss)) (cond ((and ... old-ppss ... ... ...) (syntax-ppss--update-stats 1 pt-min pos) (setq ppss ...)) (t (let ... ... ... ... ... ... ...))) (setq syntax-ppss--updated-cache t) (setq ppss-last (cons pos ppss)) (setcar cell ppss-last) (setcdr cell ppss-cache) ppss) (args-out-of-range (parse-partial-sexp (point-min) pos))))) (save-current-buffer (set-buffer buffer) (set-syntax-table table)))
  (let ((table (syntax-table)) (buffer (current-buffer))) (unwind-protect (progn (set-syntax-table (or syntax-ppss-table (syntax-table))) (let* ((cell (syntax-ppss--data)) (ppss-last (car cell)) (ppss-cache (cdr cell)) (old-ppss (cdr ppss-last)) (old-pos (car ppss-last)) (ppss nil) (pt-min (point-min))) (if (and old-pos (> old-pos pos)) (setq old-pos nil)) (condition-case nil (if (and old-pos (< ... ...)) (progn (syntax-ppss--update-stats 0 old-pos pos) (parse-partial-sexp old-pos pos nil nil old-ppss)) (cond (... ... ...) (t ...)) (setq syntax-ppss--updated-cache t) (setq ppss-last (cons pos ppss)) (setcar cell ppss-last) (setcdr cell ppss-cache) ppss) (args-out-of-range (parse-partial-sexp (point-min) pos))))) (save-current-buffer (set-buffer buffer) (set-syntax-table table))))
  syntax-ppss()
  beginning-of-defun-raw(-1)
  beginning-of-defun(-1)
  (and (not (setq found (checkdoc--next-docstring))) (beginning-of-defun -1))
  (while (and (not (setq found (checkdoc--next-docstring))) (beginning-of-defun -1)))
  (let (found) (while (and (not (setq found (checkdoc--next-docstring))) (beginning-of-defun -1))) found)
  checkdoc-next-docstring()
  (and (not wrong) (checkdoc-next-docstring))
  (while (and (not wrong) (checkdoc-next-docstring)) (setq msg (checkdoc-this-string-valid take-notes)) (if msg (setq wrong (point))))
  (save-excursion (while (and (not wrong) (checkdoc-next-docstring)) (setq msg (checkdoc-this-string-valid take-notes)) (if msg (setq wrong (point)))))
  (let ((wrong nil) (msg nil) (checkdoc-spellcheck-documentation-flag (car (memq checkdoc-spellcheck-documentation-flag '(buffer t)))) (checkdoc-autofix-flag (if take-notes 'never checkdoc-autofix-flag)) (checkdoc-generate-compile-warnings-flag (or take-notes checkdoc-generate-compile-warnings-flag))) (save-excursion (while (and (not wrong) (checkdoc-next-docstring)) (setq msg (checkdoc-this-string-valid take-notes)) (if msg (setq wrong (point))))) (if wrong (progn (goto-char wrong) (if (not take-notes) (user-error "%s" (checkdoc-error-text msg))))) (checkdoc-show-diagnostics) (if (called-interactively-p 'interactive) (message "No style warnings.")))
  checkdoc-continue(t)
  (let ((p (point))) (goto-char (point-min)) (if (and take-notes (called-interactively-p 'interactive)) (checkdoc-start-section "checkdoc-start")) (checkdoc-continue take-notes) (goto-char p) nil)
  checkdoc-start(t)
  (or (and buffer-file-name (checkdoc-comments)) (checkdoc-start take-notes) (checkdoc-message-text) (checkdoc-rogue-spaces) (if checkdoc-package-keywords-flag (progn (checkdoc-package-keywords))) (not (called-interactively-p 'interactive)) (if take-notes (checkdoc-show-diagnostics)) (message "Checking buffer for style...Done."))
  (let ((checkdoc-spellcheck-documentation-flag (car (memq checkdoc-spellcheck-documentation-flag '(buffer t)))) (checkdoc-autofix-flag (if take-notes 'never checkdoc-autofix-flag)) (checkdoc-generate-compile-warnings-flag (or take-notes checkdoc-generate-compile-warnings-flag))) (if take-notes (checkdoc-start-section "checkdoc-current-buffer")) (or (and buffer-file-name (checkdoc-comments)) (checkdoc-start take-notes) (checkdoc-message-text) (checkdoc-rogue-spaces) (if checkdoc-package-keywords-flag (progn (checkdoc-package-keywords))) (not (called-interactively-p 'interactive)) (if take-notes (checkdoc-show-diagnostics)) (message "Checking buffer for style...Done.")))
  checkdoc-current-buffer(t)
  elisp-flymake-checkdoc(#f(compiled-function (&rest args) #<bytecode -0x7c81ca94217587e>))
  apply(elisp-flymake-checkdoc #f(compiled-function (&rest args) #<bytecode -0x7c81ca94217587e>) nil)
  flymake--run-backend(elisp-flymake-checkdoc nil)
  #f(compiled-function (backend) #<bytecode -0x1832fbc28e51265>)(elisp-flymake-checkdoc)
  run-hook-wrapped(#f(compiled-function (backend) #<bytecode -0x1832fbc28e51265>) elisp-flymake-checkdoc)
  flymake-start((on-display) nil)
--8<---------------cut here---------------end--------------->8---

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 15:12:41 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 72759 <at> debbugs.gnu.org
> Date: Thu, 22 Aug 2024 13:31:16 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Thu, 22 Aug 2024 12:07:38 +0200
> >> From:  Eshel Yaron via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> 
> >> 1. emacs -Q
> >> 2. (setq open-paren-in-column-0-is-defun-start nil)
> >> 3. Insert " (foo"
> >> 4. M-x flymake-mode
> >> 5. Emacs hangs
> >> 
> >> I can reproduce this with Emacs 29 and later.
> >
> > Thanks.  Could you show the Lisp backtrace from the hang (assuming it
> > hangs in Lisp code)?
> 
> Sure, see the backtrace below.  It appears that the hang is in
> checkdoc-next-docstring, namely this loop...
> 
> --8<---------------cut here---------------start------------->8---
> (while (and (not (setq found (checkdoc--next-docstring)))
>                 (beginning-of-defun -1)))
> --8<---------------cut here---------------end--------------->8---
> 
> ...never terminates, because beginning-of-defun behaves differently with
> open-paren-in-column-0-is-defun-start set to nil.

Would it make sense to have checkdoc-next-docstring bind
open-paren-in-column-0-is-defun-start to a non-nil value?

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 14:37:01 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 72759 <at> debbugs.gnu.org
>> Date: Thu, 22 Aug 2024 13:31:16 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Date: Thu, 22 Aug 2024 12:07:38 +0200
>> >> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> >> 
>> >> 
>> >> 1. emacs -Q
>> >> 2. (setq open-paren-in-column-0-is-defun-start nil)
>> >> 3. Insert " (foo"
>> >> 4. M-x flymake-mode
>> >> 5. Emacs hangs
>> >> 
>> >> I can reproduce this with Emacs 29 and later.
>> >
>> > Thanks.  Could you show the Lisp backtrace from the hang (assuming it
>> > hangs in Lisp code)?
>> 
>> Sure, see the backtrace below.  It appears that the hang is in
>> checkdoc-next-docstring, namely this loop...
>> 
>> --8<---------------cut here---------------start------------->8---
>> (while (and (not (setq found (checkdoc--next-docstring)))
>>                 (beginning-of-defun -1)))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> ...never terminates, because beginning-of-defun behaves differently with
>> open-paren-in-column-0-is-defun-start set to nil.
>
> Would it make sense to have checkdoc-next-docstring bind
> open-paren-in-column-0-is-defun-start to a non-nil value?

Not entirely: the difference in behavior of beginning-of-defun is
unexpected, and may prove problematic in other cases as well, so it
would be best to fix the root cause IMO.  Namely, in
beginning-of-defun-raw, the fallback cond clause fails to move forward
over an sexp that does starts after the beginning of the line.

You should also be able to see this in effect with C-- C-M-a at the
beginning of a line whose contents is " (foo)".  The results vary
depending on the value of open-paren-in-column-0-is-defun-start.


Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 16:54:24 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 72759 <at> debbugs.gnu.org
> Date: Thu, 22 Aug 2024 14:37:01 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Would it make sense to have checkdoc-next-docstring bind
> > open-paren-in-column-0-is-defun-start to a non-nil value?
> 
> Not entirely: the difference in behavior of beginning-of-defun is
> unexpected, and may prove problematic in other cases as well, so it
> would be best to fix the root cause IMO.  Namely, in
> beginning-of-defun-raw, the fallback cond clause fails to move forward
> over an sexp that does starts after the beginning of the line.

How do you propose to fix the root cause, when Emacs fails to
correctly identify the beginning of a defun?  Suppose we'd want to fix
the condition of this loop:

>> (while (and (not (setq found (checkdoc--next-docstring)))
>>                 (beginning-of-defun -1)))

so it doesn't infloop -- how would you go about that, when
beginning-of-defun doesn't move and you are not at BOB?

> You should also be able to see this in effect with C-- C-M-a at the
> beginning of a line whose contents is " (foo)".  The results vary
> depending on the value of open-paren-in-column-0-is-defun-start.

Exactly!  When beginning-of-defun is confused, what are its callers
supposed to do?  They don't know better where the beginning of the
previous defun is.

Or what am I missing?

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 17:49:22 +0200

Hi,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 72759 <at> debbugs.gnu.org
>> Date: Thu, 22 Aug 2024 14:37:01 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Would it make sense to have checkdoc-next-docstring bind
>> > open-paren-in-column-0-is-defun-start to a non-nil value?
>> 
>> Not entirely: the difference in behavior of beginning-of-defun is
>> unexpected, and may prove problematic in other cases as well, so it
>> would be best to fix the root cause IMO.  Namely, in
>> beginning-of-defun-raw, the fallback cond clause fails to move forward
>> over an sexp that does starts after the beginning of the line.
>
> How do you propose to fix the root cause, when Emacs fails to
> correctly identify the beginning of a defun?  Suppose we'd want to fix
> the condition of this loop:
>
>>> (while (and (not (setq found (checkdoc--next-docstring)))
>>>                 (beginning-of-defun -1)))
>
> so it doesn't infloop -- how would you go about that, when
> beginning-of-defun doesn't move and you are not at BOB?

After taking another look, ISTM that the problem is that checkdoc
assumes that beginning-of-defun either advances point or returns nil,
but since beginning-of-defun unconditionally moves to the beginning of
the line, it can in fact find a defun ahead of point (and thus return
non-nil) but then move back to the beginning of the line, so point is
unchanged.  So the assumption in checkdoc doesn't always hold when
open-paren-in-column-0-is-defun-start is nil.  This assumption should
still hold, however, for beginning-of-defun-raw, which doesn't go back
to the beginning of the line.

This suggests the following change, which indeed seems to fix the hang:


diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
index 949ca6b74ad..65226d8ee44 100644
--- a/lisp/emacs-lisp/checkdoc.el
+++ b/lisp/emacs-lisp/checkdoc.el
@@ -981,7 +981,7 @@ checkdoc-next-docstring
 Return nil if there are no more doc strings."
   (let (found)
     (while (and (not (setq found (checkdoc--next-docstring)))
-                (beginning-of-defun -1)))
+                (beginning-of-defun-raw -1)))
     found))
 
 (defun checkdoc--next-docstring ()

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 19:10:28 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 72759 <at> debbugs.gnu.org
> Date: Thu, 22 Aug 2024 17:49:22 +0200
> 
> After taking another look, ISTM that the problem is that checkdoc
> assumes that beginning-of-defun either advances point or returns nil,
> but since beginning-of-defun unconditionally moves to the beginning of
> the line, it can in fact find a defun ahead of point (and thus return
> non-nil) but then move back to the beginning of the line, so point is
> unchanged.  So the assumption in checkdoc doesn't always hold when
> open-paren-in-column-0-is-defun-start is nil.  This assumption should
> still hold, however, for beginning-of-defun-raw, which doesn't go back
> to the beginning of the line.
> 
> This suggests the following change, which indeed seems to fix the hang:
> 
> 
> diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
> index 949ca6b74ad..65226d8ee44 100644
> --- a/lisp/emacs-lisp/checkdoc.el
> +++ b/lisp/emacs-lisp/checkdoc.el
> @@ -981,7 +981,7 @@ checkdoc-next-docstring
>  Return nil if there are no more doc strings."
>    (let (found)
>      (while (and (not (setq found (checkdoc--next-docstring)))
> -                (beginning-of-defun -1)))
> +                (beginning-of-defun-raw -1)))
>      found))

But the doc string of beginning-of-defun-raw says, inter alia:

  This is identical to function `beginning-of-defun', except that point
  does not move to the beginning of the line when `defun-prompt-regexp'
  is non-nil.                                ^^^^^^^^^^^^^^^^^^^^^^^^^^
  ^^^^^^^^^^

Does that mean defun-prompt-regexp was non-nil in your case?  The
default is nil.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 19:08:23 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 72759 <at> debbugs.gnu.org
>> Date: Thu, 22 Aug 2024 17:49:22 +0200
>> 
>> After taking another look, ISTM that the problem is that checkdoc
>> assumes that beginning-of-defun either advances point or returns nil,
>> but since beginning-of-defun unconditionally moves to the beginning of
>> the line, it can in fact find a defun ahead of point (and thus return
>> non-nil) but then move back to the beginning of the line, so point is
>> unchanged.  So the assumption in checkdoc doesn't always hold when
>> open-paren-in-column-0-is-defun-start is nil.  This assumption should
>> still hold, however, for beginning-of-defun-raw, which doesn't go back
>> to the beginning of the line.
>> 
>> This suggests the following change, which indeed seems to fix the hang:
>> 
>> 
>> diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
>> index 949ca6b74ad..65226d8ee44 100644
>> --- a/lisp/emacs-lisp/checkdoc.el
>> +++ b/lisp/emacs-lisp/checkdoc.el
>> @@ -981,7 +981,7 @@ checkdoc-next-docstring
>>  Return nil if there are no more doc strings."
>>    (let (found)
>>      (while (and (not (setq found (checkdoc--next-docstring)))
>> -                (beginning-of-defun -1)))
>> +                (beginning-of-defun-raw -1)))
>>      found))
>
> But the doc string of beginning-of-defun-raw says, inter alia:
>
>   This is identical to function `beginning-of-defun', except that point
>   does not move to the beginning of the line when `defun-prompt-regexp'
>   is non-nil.                                ^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ^^^^^^^^^^
>
> Does that mean defun-prompt-regexp was non-nil in your case?  The
> default is nil.

No, defun-prompt-regexp was (and is) the default, nil.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Thu, 22 Aug 2024 20:54:26 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 72759 <at> debbugs.gnu.org
> Date: Thu, 22 Aug 2024 19:08:23 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
> >> index 949ca6b74ad..65226d8ee44 100644
> >> --- a/lisp/emacs-lisp/checkdoc.el
> >> +++ b/lisp/emacs-lisp/checkdoc.el
> >> @@ -981,7 +981,7 @@ checkdoc-next-docstring
> >>  Return nil if there are no more doc strings."
> >>    (let (found)
> >>      (while (and (not (setq found (checkdoc--next-docstring)))
> >> -                (beginning-of-defun -1)))
> >> +                (beginning-of-defun-raw -1)))
> >>      found))
> >
> > But the doc string of beginning-of-defun-raw says, inter alia:
> >
> >   This is identical to function `beginning-of-defun', except that point
> >   does not move to the beginning of the line when `defun-prompt-regexp'
> >   is non-nil.                                ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >   ^^^^^^^^^^
> >
> > Does that mean defun-prompt-regexp was non-nil in your case?  The
> > default is nil.
> 
> No, defun-prompt-regexp was (and is) the default, nil.

So the doc string is inaccurate?

I'm trying to understand what kind of behavior change could be caused
by your proposed change, which is why what beginning-of-defun-raw does
and beginning-of-defun doesn't is important, especially if some user
options can affect that.  E.g., does anything change in this scenario
if defun-prompt-regexp is non-nil?

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Fri, 23 Aug 2024 07:54:25 +0200

Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> >> diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
>> >> index 949ca6b74ad..65226d8ee44 100644
>> >> --- a/lisp/emacs-lisp/checkdoc.el
>> >> +++ b/lisp/emacs-lisp/checkdoc.el
>> >> @@ -981,7 +981,7 @@ checkdoc-next-docstring
>> >>  Return nil if there are no more doc strings."
>> >>    (let (found)
>> >>      (while (and (not (setq found (checkdoc--next-docstring)))
>> >> -                (beginning-of-defun -1)))
>> >> +                (beginning-of-defun-raw -1)))
>> >>      found))

> I'm trying to understand what kind of behavior change could be caused
> by your proposed change, which is why what beginning-of-defun-raw does
> and beginning-of-defun doesn't is important, especially if some user
> options can affect that.  E.g., does anything change in this scenario
> if defun-prompt-regexp is non-nil?

This change is the correct also when defun-prompt-regexp is non-nil.
Take a look at beginning-of-defun, it just calls beginning-of-defun-raw
after possibly pushing a mark, and then it calls beginning-of-line.
We're not interested in pushing a mark here, neither do we want to move
back to beginning of the line after each call (that yields an infloop),
so beginning-of-defun-raw fits the bill precisely.


Best,

Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Fri, 23 Aug 2024 09:56:15 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 72759 <at> debbugs.gnu.org
> Date: Fri, 23 Aug 2024 07:54:25 +0200
> 
> Hi Eli,
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >> diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
> >> >> index 949ca6b74ad..65226d8ee44 100644
> >> >> --- a/lisp/emacs-lisp/checkdoc.el
> >> >> +++ b/lisp/emacs-lisp/checkdoc.el
> >> >> @@ -981,7 +981,7 @@ checkdoc-next-docstring
> >> >>  Return nil if there are no more doc strings."
> >> >>    (let (found)
> >> >>      (while (and (not (setq found (checkdoc--next-docstring)))
> >> >> -                (beginning-of-defun -1)))
> >> >> +                (beginning-of-defun-raw -1)))
> >> >>      found))
> 
> > I'm trying to understand what kind of behavior change could be caused
> > by your proposed change, which is why what beginning-of-defun-raw does
> > and beginning-of-defun doesn't is important, especially if some user
> > options can affect that.  E.g., does anything change in this scenario
> > if defun-prompt-regexp is non-nil?
> 
> This change is the correct also when defun-prompt-regexp is non-nil.
> Take a look at beginning-of-defun, it just calls beginning-of-defun-raw
> after possibly pushing a mark, and then it calls beginning-of-line.
> We're not interested in pushing a mark here, neither do we want to move
> back to beginning of the line after each call (that yields an infloop),
> so beginning-of-defun-raw fits the bill precisely.

Thanks, feel free to install this, then.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Fri, 23 Aug 2024 10:33:55 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 72759 <at> debbugs.gnu.org
>> Date: Fri, 23 Aug 2024 07:54:25 +0200
>> 
>> Hi Eli,
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> >> diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
>> >> >> index 949ca6b74ad..65226d8ee44 100644
>> >> >> --- a/lisp/emacs-lisp/checkdoc.el
>> >> >> +++ b/lisp/emacs-lisp/checkdoc.el
>> >> >> @@ -981,7 +981,7 @@ checkdoc-next-docstring
>> >> >>  Return nil if there are no more doc strings."
>> >> >>    (let (found)
>> >> >>      (while (and (not (setq found (checkdoc--next-docstring)))
>> >> >> -                (beginning-of-defun -1)))
>> >> >> +                (beginning-of-defun-raw -1)))
>> >> >>      found))
>> 
>> > I'm trying to understand what kind of behavior change could be caused
>> > by your proposed change, which is why what beginning-of-defun-raw does
>> > and beginning-of-defun doesn't is important, especially if some user
>> > options can affect that.  E.g., does anything change in this scenario
>> > if defun-prompt-regexp is non-nil?
>> 
>> This change is the correct also when defun-prompt-regexp is non-nil.
>> Take a look at beginning-of-defun, it just calls beginning-of-defun-raw
>> after possibly pushing a mark, and then it calls beginning-of-line.
>> We're not interested in pushing a mark here, neither do we want to move
>> back to beginning of the line after each call (that yields an infloop),
>> so beginning-of-defun-raw fits the bill precisely.
>
> Thanks, feel free to install this, then.

Thank you, is this OK for the release branch or would the master branch
be better?


Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Fri, 23 Aug 2024 16:14:29 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 72759 <at> debbugs.gnu.org
> Date: Fri, 23 Aug 2024 10:33:55 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks, feel free to install this, then.
> 
> Thank you, is this OK for the release branch or would the master branch
> be better?

Release branch is okay for this, IMO.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72759 <at> debbugs.gnu.org
Subject: Re: bug#72759: 31.0.50; Emacs hangs with
 open-paren-in-column-0-is-defun-start set to nil
Date: Fri, 23 Aug 2024 17:22:12 +0200

close 72759 30.1
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 72759 <at> debbugs.gnu.org
>> Date: Fri, 23 Aug 2024 10:33:55 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Thanks, feel free to install this, then.
>> 
>> Thank you, is this OK for the release branch or would the master branch
>> be better?
>
> Release branch is okay for this, IMO.

Done in commit 44c26140b6e, so I'm closing this bug.


Thanks,

Eshel

Previous Next

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