GNU bug report logs -
#68893
30.0.50; pixel-fill-region errors when folding message headers in Gnus
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 68893 in the body.
You can then email your comments to 68893 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68893
; Package
emacs
.
(Fri, 02 Feb 2024 15:34:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 02 Feb 2024 15:34:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68893
; Package
emacs
.
(Fri, 02 Feb 2024 15:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 68893 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68893
; Package
emacs
.
(Fri, 02 Feb 2024 19:36:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 68893 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 02 Feb 2024 17:52:48 +0200 Eli Zaretskii <eliz <at> 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 <at> 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 <at> 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:
[Message part 2 (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
(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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68893
; Package
emacs
.
(Fri, 02 Feb 2024 19:40:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 68893 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 68893 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68893
; Package
emacs
.
(Fri, 02 Feb 2024 21:38:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 68893 <at> debbugs.gnu.org (full text, mbox):
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.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 03 Feb 2024 09:13:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
bug acknowledged by developer.
(Sat, 03 Feb 2024 09:13:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 68893-done <at> debbugs.gnu.org (full text, mbox):
> 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.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 03 Feb 2024 09:13:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Katsumi Yamaoka <yamaoka <at> jpl.org>
:
bug acknowledged by developer.
(Sat, 03 Feb 2024 09:13:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 03 Feb 2024 09:13:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
No Wayman <iarchivedmywholelife <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 03 Feb 2024 09:13:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 02 Mar 2024 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 112 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.