bug#72771: 31.0.50; shr html renderer throwing "Specified window is not displaying the current buffer"

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 24 Aug 2024 12:42:04 -0700
> Cc: R.Stewart@hw.ac.uk, 72771@debbugs.gnu.org, kevin.legouguec@gmail.com
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >> I think the problem is getting the actual face, which works for simple
> >> cases via 'get-text-property', but not for more complex ones, e.g. when
> >> the 'face' property is a list; 'face-font' raises an error in that case.
> >> Effectively what I want would be a Lisp version of
> >> 'face_at_buffer_position', but that requires a window object anyway, so
> >> I'm back to the original problem...
> > 
> > What's wrong with face-at-point?
> 
> I don't know if that gets me quite what I want; it seems to be 
> equivalent to 'get-text-property' for this case. The real problem is 
> that I can't pass a list of faces to 'face-font'. In a case like that, 
> any one of the faces in the list could be setting the font, so I can't 
> just pass the first face in the list (or some other simplification).
> 
> I'm sure I could iterate over the faces, but that seems more complex 
> than the 'font-at' trick.

The 'font-at' trick might seem simple, but it has its caveats, as
mentioned before.  You basically use settings of a wrong window.  This
could be fine in simple cases, but not in all of them.  For example,
there are window-specific overlays and other features.

> >>>    . use buffer-text-pixel-size or string-pixel-width to measure the
> >>>      width of a string of a single SPC character
> >>
> >> I think this wouldn't work since I want the average font width, not the
> >> width of SPC.
> > 
> > Then use a few different characters and take their average width.
> 
> Well, I just want the "average-width" parameter as reported by the font 
> object (falling back to "space-width"), since Emacs has already computed 
> that.

If you look at how this is computed, you will see that at least some
font backends do exactly what I said: they measure the width of a
string of different characters and divide that by the number of
characters.

> Trying to re-approximate that already-computed value doesn't seem 
> like the right thing to do when I can jump over a small hurdle to get 
> the existing value.

Again, the simplicity here is deceptive.

> > And I think you place too much faith in the average-width parameter of
> > a font.  It can fail you.  The display engine uses:
> > 
> > 	      char_width = (font->average_width
> > 	                    ? font->average_width
> > 	                    : font->space_width);
> 
> Thanks for prompting me to re-read the manual on this. I'd 
> misinterpreted this passage in the documentation for 'query-font':
> 
> > average-width > The average width of the font characters. If this is zero, Emacs uses
> > the value of space-width instead, when it calculates text layout on
> > display.
> 
> Previously I thought it meant that this element of the vector would hold 
> the average-width, or if that was zero, hold (a copy of) the 
> space-width. But checking the code, I see that's not right, and I should 
> be sure to mimic what the display engine does above.
> 
> Maybe this passage could be reworded to something like this: "This value 
> may be zero.  In that case, for calculating text layout on display, 
> Emacs will consult the space-width instead."

I don't see how this is different from the text we already have,
sorry.

> >> In light of the above, I think what I have now might be the best way to
> >> do it for the time being
> > 
> > Do you still think that?
> 
> Aside from the above issue with 'space-width', yes (fixed in the 
> attached patch).

<Shrug>Fine by me.