GNU bug report logs -
#72771
31.0.50; shr html renderer throwing "Specified window is not displaying the current buffer"
Previous Next
Reported by: Rob Stewart <R.Stewart <at> hw.ac.uk>
Date: Fri, 23 Aug 2024 08:22:02 UTC
Severity: normal
Found in version 31.0.50
Done: Jim Porter <jporterbugs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #20 received at 72771 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 23 Aug 2024 15:39:00 -0700
> Cc: Rob Stewart <R.Stewart <at> hw.ac.uk>, 72771 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
>
> Here's a patch. I've tested this in a few configurations (in the current
> window, in a buffer that's not being displayed, in a terminal Emacs) and
> it all seems to work.
>
> One question, Eli: is there a better way than I'm using to get the font
> that would be used for a character in the buffer? When the buffer is
> being displayed in a window, '(font-at position window)' works, but that
> doesn't address this bug, where the buffer isn't displayed. (The font
> that we get back doesn't have to be 100% accurate; just a good guess
> should be fine for this case.)
AFAIU, the code needs the width of the space character of a font used
to show some text, is that correct?
And the patch solves the problem of font-at by pretending that the
relevant text is displayed in the current window, is that correct?
Alternatives to the solution in the patch are:
. temporarily display the buffer in some window (if there is already
a window showing the buffer, use with-selected-window)
. use buffer-text-pixel-size or string-pixel-width to measure the
width of a string of a single SPC character
. 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)
This bug report was last modified 268 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.