Subject: Re: bug#20808: 24.5; Emacs looping with 100% CPU at line 15287 (?) of xdisp.c
From: Eli Zaretskii <[email-masked]>
To: [email-masked] (N. Jackson)
Cc: [email-masked]
Date: Wed, 17 Jun 2015 20:22:16 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: [email-masked] (N. Jackson)
> Cc: [email-masked]
> Date: Wed, 17 Jun 2015 08:30:18 -0300
> 
> As for "near" the end of the buffer, yes, for some value of "near".
> 
> That webpage has some text at the top and below that are images only. It
> turns out (I just checked with an even shorter window), that Eww/shr is
> displaying all of those images on the same line and that line is the
> last line of the buffer.
> 
> The images get sized (by Eww/shr?) so that each of them fits within the
> window height and with the even shorter window I just tried (maybe four
> or five text lines high), they are sufficiently small that the entire
> line of them fits within the width of the window.
> 
> But with the eleven-text-lines-high window that the webpage opens in
> from Gnus, the line of images is wider than the window so it is wrapped
> to two "lines" or rows in the window.
> 
> The infloop always occurs when the window is showing the top row of
> images (and a little bit of the top of the tallest image in the second
> row), so (because the line of images is the last line of the buffer),
> yes, the infloop occurs when scrolling near the last line of the buffer;
> however it is not the last line of the window, but rather, more like
> half way up it, if that makes any sense.

Sorry, when I was talking about "lines", I really meant "screen
lines", i.e. horizontal rows of "display elements", be it character
glyphs or images.  I didn't mean "lines" as the measure of height.

> I hope that helps.

It does, thanks.

I've pushed the change.  Thanks a lot for your help in debugging this.