bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Lars Ingebrigtsen]

With the following HTML, on this laptop with whatever font Emacs is
using right now, 80 characters wide, the following is one pixel too
wide:

<P>A young Quakers group in Nottingham, England released this 30-minute podcast of a silent meeting, complete with the ambient room sounds. John Cage would be proud. From <a href="https://www.theguardian.com/media/2018/apr/08/an-oasis-of-calm-quaker-groups-30-minutes-of-silence-podcast">The Guardian</a>:

The "m" in "room" extends too far.

I'm just posting this here to remind me to fix it; it'll be difficult
for anybody else to reproduce exactly.


In GNU Emacs 27.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2018-04-15 built on corrigan
Repository revision: 1c16fbd1b281a46b07028ca78dbaab9a0ec6fd2f
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> With the following HTML, on this laptop with whatever font Emacs is
> using right now, 80 characters wide, the following is one pixel too
> wide:

This is the problem, I think:

(- (window-body-width nil t)
   (* 2 (frame-char-width))
   (if (and (null shr-width)
            (not (shr--have-one-fringe-p)))
       (* (frame-char-width) 2)
     0))

This kludge is how shr computes how many pixels the window has
horizontally.

Surely there's a better way to find the practical "inner" width of a
window; i.e., the space where we can put text and stuff?  Does anybody
know?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Surely there's a better way to find the practical "inner" width of a
> window; i.e., the space where we can put text and stuff?  Does anybody
> know?

(If I decrease the width by 1 pixel, then things are filled correctly in
my test case.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 17 Apr 2018 19:03:38 +0200
> 
> (- (window-body-width nil t)
>    (* 2 (frame-char-width))
>    (if (and (null shr-width)
>             (not (shr--have-one-fringe-p)))
>        (* (frame-char-width) 2)
>      0))
> 
> This kludge is how shr computes how many pixels the window has
> horizontally.

Why is that a kludge?

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Tue, 17 Apr 2018 19:03:38 +0200
>> 
>> (- (window-body-width nil t)
>>    (* 2 (frame-char-width))
>>    (if (and (null shr-width)
>>             (not (shr--have-one-fringe-p)))
>>        (* (frame-char-width) 2)
>>      0))
>> 
>> This kludge is how shr computes how many pixels the window has
>> horizontally.
>
> Why is that a kludge?

Well, perhaps not a kludge, but very complicated for something you'd
think would be a metric that's more easily available.

And it seems to be 1 pixel wrong.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 31196@debbugs.gnu.org
> Date: Tue, 17 Apr 2018 19:43:00 +0200
> 
> >> (- (window-body-width nil t)
> >>    (* 2 (frame-char-width))
> >>    (if (and (null shr-width)
> >>             (not (shr--have-one-fringe-p)))
> >>        (* (frame-char-width) 2)
> >>      0))
> >> 
> >> This kludge is how shr computes how many pixels the window has
> >> horizontally.
> >
> > Why is that a kludge?
> 
> Well, perhaps not a kludge, but very complicated for something you'd
> think would be a metric that's more easily available.

The metric is indeed easily available: that's what window-body-width
returns.  But how can it know what will you do with the metric?  The
fact that you want to account for one or two fringes etc. is something
specific to the application, no?

> And it seems to be 1 pixel wrong.  :-)

Is it wrong, or are you counting pixels as in 0, 1, ... N, assuming
that the Nth pixel is still in the window?

bug#31196: 27.0.50; shr sometimes doesn't break lines as it should

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The metric is indeed easily available: that's what window-body-width
> returns.  But how can it know what will you do with the metric?  The
> fact that you want to account for one or two fringes etc. is something
> specific to the application, no?

Well, I think the common use case when you're asking how wide a window
is is that you're going to put something in that window and you want to
scale it to that window somehow.  Since the fringes aren't part of that
area, it's weird that you have to dig deeply into those obscure matters
to find the area, I think.

Perhaps `window-body-width' should have a parameter that makes it return
what you'd thing it should return?  (By "you" I mean "I", of course.)

>> And it seems to be 1 pixel wrong.  :-)
>
> Is it wrong, or are you counting pixels as in 0, 1, ... N, assuming
> that the Nth pixel is still in the window?

It's possible that there's an off-by-one error somewhere.

I'll just fix this by putting a -1 into the form and leave it be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no