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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stephen Berman <stephen.berman <at> gmx.net>
Subject: bug#68893: closed (Re: bug#68893: 30.0.50; pixel-fill-region
 errors when folding message headers in Gnus)
Date: Sat, 03 Feb 2024 09:13:02 +0000

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

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 68893 <at> debbugs.gnu.org.

-- 
68893: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68893
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: stephen.berman <at> gmx.net, 68893-done <at> debbugs.gnu.org
Subject: Re: bug#68893: 30.0.50; pixel-fill-region errors when folding
 message headers in Gnus
Date: Sat, 03 Feb 2024 11:11:54 +0200

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: Stephen Berman <stephen.berman <at> gmx.net>,  68893 <at> debbugs.gnu.org
> Date: Fri, 02 Feb 2024 16:37:46 -0500
> 
> Eli Zaretskii <eliz <at> 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.

[Message part 3 (message/rfc822, inline)]

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; pixel-fill-region errors when folding message headers in Gnus
Date: Fri, 02 Feb 2024 16:33:00 +0100

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

Previous Next

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