all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
@ 2024-08-22 10:07 Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-22 10:56 ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-22 10:07 UTC (permalink / raw)
  To: 72759


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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 10:07 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
@ 2024-08-22 10:56 ` Eli Zaretskii
  2024-08-22 11:31   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-22 10:56 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

> 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@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)?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 10:56 ` Eli Zaretskii
@ 2024-08-22 11:31   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-22 12:12     ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-22 11:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

Eli Zaretskii <eliz@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@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---







^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 11:31   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-22 12:12     ` Eli Zaretskii
  2024-08-22 12:37       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-22 12:12 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 72759@debbugs.gnu.org
> Date: Thu, 22 Aug 2024 13:31:16 +0200
> 
> Eli Zaretskii <eliz@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@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?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 12:12     ` Eli Zaretskii
@ 2024-08-22 12:37       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-22 13:54         ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-22 12:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: 72759@debbugs.gnu.org
>> Date: Thu, 22 Aug 2024 13:31:16 +0200
>> 
>> Eli Zaretskii <eliz@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@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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 12:37       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-22 13:54         ` Eli Zaretskii
  2024-08-22 15:49           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-22 13:54 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 72759@debbugs.gnu.org
> Date: Thu, 22 Aug 2024 14:37:01 +0200
> 
> Eli Zaretskii <eliz@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?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 13:54         ` Eli Zaretskii
@ 2024-08-22 15:49           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-22 16:10             ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-22 15:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: 72759@debbugs.gnu.org
>> Date: Thu, 22 Aug 2024 14:37:01 +0200
>> 
>> Eli Zaretskii <eliz@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 ()





^ permalink raw reply related	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 15:49           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-22 16:10             ` Eli Zaretskii
  2024-08-22 17:08               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-22 16:10 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 72759@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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 16:10             ` Eli Zaretskii
@ 2024-08-22 17:08               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-22 17:54                 ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-22 17:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: 72759@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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 17:08               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-22 17:54                 ` Eli Zaretskii
  2024-08-23  5:54                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-22 17:54 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 72759@debbugs.gnu.org
> Date: Thu, 22 Aug 2024 19:08:23 +0200
> 
> 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))
> >
> > 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?






^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-22 17:54                 ` Eli Zaretskii
@ 2024-08-23  5:54                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-23  6:56                     ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-23  5:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

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.


Best,

Eshel






^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-23  5:54                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-23  6:56                     ` Eli Zaretskii
  2024-08-23  8:33                       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-23  6:56 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

> 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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-23  6:56                     ` Eli Zaretskii
@ 2024-08-23  8:33                       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-23 13:14                         ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-23  8:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-23  8:33                       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-23 13:14                         ` Eli Zaretskii
  2024-08-23 15:22                           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-08-23 13:14 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 72759

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#72759: 31.0.50; Emacs hangs with open-paren-in-column-0-is-defun-start set to nil
  2024-08-23 13:14                         ` Eli Zaretskii
@ 2024-08-23 15:22                           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 15+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-23 15:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 72759

close 72759 30.1
quit

Eli Zaretskii <eliz@gnu.org> writes:

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2024-08-23 15:22 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-22 10:07 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
2024-08-22 10:56 ` Eli Zaretskii
2024-08-22 11:31   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 12:12     ` Eli Zaretskii
2024-08-22 12:37       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 13:54         ` Eli Zaretskii
2024-08-22 15:49           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 16:10             ` Eli Zaretskii
2024-08-22 17:08               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 17:54                 ` Eli Zaretskii
2024-08-23  5:54                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-23  6:56                     ` Eli Zaretskii
2024-08-23  8:33                       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-23 13:14                         ` Eli Zaretskii
2024-08-23 15:22                           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.