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

[Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: 72759@debbugs.gnu.org
>> Date: Fri, 23 Aug 2024 07:54:25 +0200
>> 
>> Hi Eli,
>> 
>> Eli Zaretskii <eliz@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