GNU bug report logs - #50406
fill-paragraph error

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 50406 in the body.
You can then email your comments to 50406 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: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: fill-paragraph error
Date: Sun, 05 Sep 2021 19:10:10 +0300

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

Please try to open the attached file in emacs -Q, and after moving point
to the beginning of the 3rd line, type 'M-q'.  When debug-on-error is t,
it fails with such backtrace:

Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)")
  re-search-backward("[ \11]\\|\\c|.\\|.\\c|" 280 0)
  fill-move-to-break-point(280)
  fill-region-as-paragraph(184 210 nil nil 186)
  fill-comment-paragraph(nil)
  fill-paragraph(nil t)
  funcall-interactively(fill-paragraph nil t)
  command-execute(fill-paragraph)

BTW, evaluating debug-on-error in *scratch* shows t by default,
but 'C-h v debug-on-error' shows it's nil actually, strange.

[fill-paragraph (application/octet-stream, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50406 <at> debbugs.gnu.org
Subject: Re: bug#50406: fill-paragraph error
Date: Mon, 06 Sep 2021 11:18:11 +0200

Juri Linkov <juri <at> linkov.net> writes:

> Please try to open the attached file in emacs -Q, and after moving point
> to the beginning of the 3rd line, type 'M-q'.  When debug-on-error is t,
> it fails with such backtrace:
>
> Debugger entered--Lisp error: (error "Invalid search bound (wrong side
> of point)")
>   re-search-backward("[ \11]\\|\\c|.\\|.\\c|" 280 0)
>   fill-move-to-break-point(280)

I can reproduce this bug, too.

> BTW, evaluating debug-on-error in *scratch* shows t by default,
> but 'C-h v debug-on-error' shows it's nil actually, strange.

With `C-x C-e'?  Then this happens:

---
If ‘eval-expression-debug-on-error’ is non-nil, which is the default,
this command arranges for all errors to enter the debugger.
---


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

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50406 <at> debbugs.gnu.org
Subject: Re: bug#50406: fill-paragraph error
Date: Mon, 06 Sep 2021 18:14:08 +0300

>> Debugger entered--Lisp error: (error "Invalid search bound (wrong side
>> of point)")
>>   re-search-backward("[ \11]\\|\\c|.\\|.\\c|" 280 0)
>>   fill-move-to-break-point(280)
>
> I can reproduce this bug, too.
>
>> BTW, evaluating debug-on-error in *scratch* shows t by default,
>> but 'C-h v debug-on-error' shows it's nil actually, strange.
>
> With `C-x C-e'?

Yep.

> Then this happens:
>
> ---
> If ‘eval-expression-debug-on-error’ is non-nil, which is the default,
> this command arranges for all errors to enter the debugger.
> ---

This is fine, just a little strange.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50406 <at> debbugs.gnu.org
Subject: Re: bug#50406: fill-paragraph error
Date: Mon, 22 Aug 2022 22:46:33 +0200

Juri Linkov <juri <at> linkov.net> writes:

> Please try to open the attached file in emacs -Q, and after moving point
> to the beginning of the 3rd line, type 'M-q'.  When debug-on-error is t,
> it fails with such backtrace:
>
> Debugger entered--Lisp error: (error "Invalid search bound (wrong side
> of point)")
>   re-search-backward("[ \11]\\|\\c|.\\|.\\c|" 280 0)
>   fill-move-to-break-point(280)
>   fill-region-as-paragraph(184 210 nil nil 186)
>   fill-comment-paragraph(nil)
>   fill-paragraph(nil t)
>   funcall-interactively(fill-paragraph nil t)
>   command-execute(fill-paragraph)

This doesn't happen now in Emacs 29.  Instead I get:

abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc ; def
											    ; def
											    ; def
											    ; def
											    ; def
											    ; ghi

Is that the result we're supposed to get, though?  I'm not at all sure
how fill-paragraph/comment-start are supposed to interact here.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50406 <at> debbugs.gnu.org
Subject: Re: bug#50406: fill-paragraph error
Date: Tue, 23 Aug 2022 10:35:27 +0300

>> Please try to open the attached file in emacs -Q, and after moving point
>> to the beginning of the 3rd line, type 'M-q'.  When debug-on-error is t,
>> it fails with such backtrace:
>>
>> Debugger entered--Lisp error: (error "Invalid search bound (wrong side
>> of point)")
>>   re-search-backward("[ \11]\\|\\c|.\\|.\\c|" 280 0)
>>   fill-move-to-break-point(280)
>>   fill-region-as-paragraph(184 210 nil nil 186)
>>   fill-comment-paragraph(nil)
>>   fill-paragraph(nil t)
>>   funcall-interactively(fill-paragraph nil t)
>>   command-execute(fill-paragraph)
>
> This doesn't happen now in Emacs 29.  Instead I get:
>
> abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc ; def
> 											    ; def
> 											    ; def
> 											    ; def
> 											    ; def
> 											    ; ghi
>
> Is that the result we're supposed to get, though?  I'm not at all sure
> how fill-paragraph/comment-start are supposed to interact here.

This is what it always did in all earlier versions until the recent
breakage that is fixed now.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50406 <at> debbugs.gnu.org
Subject: Re: bug#50406: fill-paragraph error
Date: Tue, 23 Aug 2022 12:46:09 +0200

Juri Linkov <juri <at> linkov.net> writes:

> This is what it always did in all earlier versions until the recent
> breakage that is fixed now.

OK, then I guess everything works here, and I'm closing this bug report.

Previous Next

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