bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

When I type `t' (gnus-summary-toggle-header) on many (but not all)
articles in the Gnus Summary buffer, I get an error in pixel-fill-region
that the indentation is wider than the fill width.  I can reproduce the
error as follows:

0. emacs -Q
1. Enable debug-on-error.
2. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.io
   RET', then `C-s emacs.bugs RET RET 1 RET' to enter the Gnus Summary
   buffer showing the latest article in the gnu.emacs.bugs group.  Then
   type `j' and at the prompt paste the following Message-ID (of an
   article that reliably induces the error) into the minibuffer:
   <CALDnm52NYEfCacWrCxi1JywLZ6O5rRRkx9H9qAod5DcM9ayJ-w@mail.gmail.com>
3. Type `t'.  This raises an error and produces the following backtrace:

Debugger entered--Lisp error: (error "The indentation (640) is wider than the fill width (623)")
  error("The indentation (%s) is wider than the fill width (%s)" 640 623)
  pixel-fill-region(101 129 623)
  gnus-article-treat-fold-headers()
  gnus-treat-article(head)
  gnus-summary-toggle-header(nil)
  funcall-interactively(gnus-summary-toggle-header nil)
  command-execute(gnus-summary-toggle-header)

I tried taking a closer look with Edebug.  First, I cleared the
backtrace and refreshed the article (by typing `g' in the Summary
buffer), then instrumented pixel-fill-region for Edebug, typed `t' on
the article again, and when execution stopped in pixel-fill-region I
opened a new frame and switched to the Article buffer, which was now
narrowed to the first header:

Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail

I then stepped through pixel-fill-region: the value of `start' is 2, and
window-text-pixel-size returns `(8 . 17)'.  I continued to the next
header:

From: João Távora <joaotavora@gmail.com>

and stepped through pixel-fill-region again: `start' is now 60 and
window-text-pixel-size again returns `(8 . 17)'.  Repeating, I got the
third header:

Newsgroups: gmane.emacs.bugs

and continued stepping: `start' is now 101, but now
window-text-pixel-size returns `(634 . 34)' and this caused the error (I
don't know why the car was 634 when edebugging but 640 without).

I don't use gnus-summary-toggle-header very often so I don't know when
this bug started, but it does not happen in emacs-29.  When I carry out
the above recipe and step through pixel-fill-region in emacs-29, I get
the same values for the first two headers, but for the third header
window-text-pixel-size returns `(0 . 17)', which does not cause an
error, nor do the remaining headers.

I saw that there are some differences between window_text_pixel_size in
master and in emacs-29, so I tried running emacs under gdb, setting a
breakpoint at window_text_pixel_size, and carrying out the recipe, but
that's a fairly complex function and I couldn't see how to find out
where the differing values are coming from.

I don't know if it's relevant, but my build from master is with native
compilation while my build from emacs-29 is not.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.18.0) of 2024-02-02 built on strobelfs2
Repository revision: 72b1379f0795a5e2e9c57615c0b1d78c0b97cd1f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101009
System Description: Linux From Scratch r12.0-112

Configured using:
 'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

[Eli Zaretskii]

merge 68893 67791
thanks

> Date: Fri, 02 Feb 2024 16:33:00 +0100
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When I type `t' (gnus-summary-toggle-header) on many (but not all)
> articles in the Gnus Summary buffer, I get an error in pixel-fill-region
> that the indentation is wider than the fill width.  I can reproduce the
> error as follows:
> 
> 0. emacs -Q
> 1. Enable debug-on-error.
> 2. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.io
>    RET', then `C-s emacs.bugs RET RET 1 RET' to enter the Gnus Summary
>    buffer showing the latest article in the gnu.emacs.bugs group.  Then
>    type `j' and at the prompt paste the following Message-ID (of an
>    article that reliably induces the error) into the minibuffer:
>    <CALDnm52NYEfCacWrCxi1JywLZ6O5rRRkx9H9qAod5DcM9ayJ-w@mail.gmail.com>
> 3. Type `t'.  This raises an error and produces the following backtrace:

This is another duplicate of bug#67791.  Please see there for the
analysis and the proposed solutions.

Thanks.

bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Fri, 02 Feb 2024 17:52:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

> merge 68893 67791
> thanks
>
>> Date: Fri, 02 Feb 2024 16:33:00 +0100
>> From:  Stephen Berman via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> When I type `t' (gnus-summary-toggle-header) on many (but not all)
>> articles in the Gnus Summary buffer, I get an error in pixel-fill-region
>> that the indentation is wider than the fill width.  I can reproduce the
>> error as follows:
>>
>> 0. emacs -Q
>> 1. Enable debug-on-error.
>> 2. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.io
>>    RET', then `C-s emacs.bugs RET RET 1 RET' to enter the Gnus Summary
>>    buffer showing the latest article in the gnu.emacs.bugs group.  Then
>>    type `j' and at the prompt paste the following Message-ID (of an
>>    article that reliably induces the error) into the minibuffer:
>>    <CALDnm52NYEfCacWrCxi1JywLZ6O5rRRkx9H9qAod5DcM9ayJ-w@mail.gmail.com>
>> 3. Type `t'.  This raises an error and produces the following backtrace:
>
> This is another duplicate of bug#67791.  Please see there for the
> analysis and the proposed solutions.

Ah, I actually had seen that report and also the recent other one that
you merged with it, but unfortunately I didn't remember them when I
encountered the issue myself today.  Thanks for the pointer.  And
indeed, not only does Katsumi Yamaoka's patch to
gnus-article-treat-fold-headers fix the problem for me too, but also
your suggestion to apply the fix to pixel-fill-region instead, as in the
following patch, works just as well:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pixel-fill-region patch --]
[-- Type: text/x-patch, Size: 589 bytes --]

diff --git a/lisp/textmodes/pixel-fill.el b/lisp/textmodes/pixel-fill.el
index 25c0b46cee9..dcd57acc2e5 100644
--- a/lisp/textmodes/pixel-fill.el
+++ b/lisp/textmodes/pixel-fill.el
@@ -73,7 +73,8 @@ pixel-fill-region
 If START isn't at the start of a line, the horizontal position of
 START, converted to pixel units, will be used as the indentation
 prefix on subsequent lines."
-  (save-excursion
+  (save-window-excursion
+    (set-window-buffer nil (current-buffer))
     (goto-char start)
     (let ((indentation
            (car (window-text-pixel-size nil (line-beginning-position)

[-- Attachment #3: Type: text/plain, Size: 319 bytes --]


(I also tried your suggestion to use buffer-text-pixel-size in place of
window-text-pixel-size in pixel-fill-region, and while that prevented
the error, it resulted in irregular and very large indentation of the
continuations of overlong headers, and I didn't immediately see an easy
way to avoid that.)

Steve Berman

bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 68893@debbugs.gnu.org
> Date: Fri, 02 Feb 2024 20:35:29 +0100
> 
> Ah, I actually had seen that report and also the recent other one that
> you merged with it, but unfortunately I didn't remember them when I
> encountered the issue myself today.  Thanks for the pointer.  And
> indeed, not only does Katsumi Yamaoka's patch to
> gnus-article-treat-fold-headers fix the problem for me too, but also
> your suggestion to apply the fix to pixel-fill-region instead, as in the
> following patch, works just as well:
> 
> diff --git a/lisp/textmodes/pixel-fill.el b/lisp/textmodes/pixel-fill.el
> index 25c0b46cee9..dcd57acc2e5 100644
> --- a/lisp/textmodes/pixel-fill.el
> +++ b/lisp/textmodes/pixel-fill.el
> @@ -73,7 +73,8 @@ pixel-fill-region
>  If START isn't at the start of a line, the horizontal position of
>  START, converted to pixel units, will be used as the indentation
>  prefix on subsequent lines."
> -  (save-excursion
> +  (save-window-excursion
> +    (set-window-buffer nil (current-buffer))
>      (goto-char start)
>      (let ((indentation
>             (car (window-text-pixel-size nil (line-beginning-position)

No Wayman, does the above fix the problem for you as well?

Thanks.

bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

[No Wayman]

Eli Zaretskii <eliz@gnu.org> writes:

> No Wayman, does the above fix the problem for you as well?
>
> Thanks.

Yes. That also fixes the issue.

bug#68893: 30.0.50; pixel-fill-region errors when folding message headers in Gnus

[Eli Zaretskii]

> From: No Wayman <iarchivedmywholelife@gmail.com>
> Cc: Stephen Berman <stephen.berman@gmx.net>,  68893@debbugs.gnu.org
> Date: Fri, 02 Feb 2024 16:37:46 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No Wayman, does the above fix the problem for you as well?
> >
> > Thanks.
> 
> Yes. That also fixes the issue.

Thanks, I installed on the emacs-29 branch a somewhat different patch,
which uses save-window-excursion _and_ save-excursion, because we also
need to preserve point position in the current buffer.

Let me know if the change causes any further problem.  For now, I'm
closing this bug.