GNU bug report logs - #72771
31.0.50; shr html renderer throwing "Specified window is not displaying the current buffer"

Previous Next

Full log

Message #29 received at 72771 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: R.Stewart <at> hw.ac.uk, 72771 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
Subject: Re: bug#72771: 31.0.50; shr html renderer throwing "Specified window
 is not displaying the current buffer"
Date: Sat, 24 Aug 2024 12:42:04 -0700

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

On 8/24/2024 12:01 PM, Eli Zaretskii wrote:
>> Date: Sat, 24 Aug 2024 10:10:06 -0700
>> Cc: R.Stewart <at> hw.ac.uk, 72771 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>>>    . use the font obtained from (face-font 'default) (or the actual face
>>>      of the text, if you can get at it easily), like this:
>>>
>>>         (aref (font-info (face-font 'default)) 10)
>>
>> 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.

>>>    . 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. 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. Then I also don't have to worry about the 
performance impact of computing the approximation many times (or finding 
a place to cache it).

> 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." (Or maybe this is just a 
"me" problem...)

>> 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). The 'font-at' trick seems like it gets me the font 
object with the least amount of fuss, and then I can I can retrieve the 
pixel-size of the 'width' unit as used by the display engine when 
handling the pixel specification.

Maybe some higher-level function would be useful here but I don't know 
if this is a very common thing people need to do either...

[0001-Improve-computation-of-indent-depth-in-SHR-and-visua.patch (text/plain, attachment)]

Previous Next

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