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

Previous Next

Full log

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?

Previous Next

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