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" <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:

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