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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72771 in the body.
You can then email your comments to 72771 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Rob Stewart <R.Stewart <at> hw.ac.uk>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; shr html renderer throwing "Specified window is not
 displaying the current buffer"
Date: Fri, 23 Aug 2024 09:15:52 +0100

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

When attempting to open the attached (anonymised) message with mm-text-html-renderer set to `shr`, I get this bracktrace:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "Specified window is not displaying the current buffer")
  shr-indent()
  shr-fill-line()
  shr-fill-lines(13724 15455)
  shr-insert-document((html ((xmlns:o . .))))
  mm-shr((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
  mm-inline-text-html((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
  mm-display-inline((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
  mm-display-part((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
  gnus-mime-display-alternative(((#<buffer  *mm*-410985> ("text/plain" (charset . "Windows-1252")) quoted-printable nil ("inline") nil nil nil) (#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil)) nil nil 1)
  gnus-mime-display-part((#("multipart/alternative" ...)))
  gnus-display-mime(nil)
  #f(compiled-function (&optional ihandles) #<bytecode -0xcb4ad9361861f2a>)()
  gnus-article-prepare-display()
  mu4e--view-render-buffer((:path ...))
  mu4e-view((:path ...))
  mu4e~headers-view-handler((:path ...))
--8<---------------cut here---------------end--------------->8---

I've been asked here:

https://github.com/djcb/mu/issues/2747#issuecomment-2305245669

to report this as an Emacs bug/incompatibility.

I'm using Emacs build 3d1d4f109ed4115256a08c74eeb704259d91c9f4 (21 August 2024).

Best wishes,

--
Rob Stewart
________________________________

Founded in 1821, Heriot-Watt is a leader in ideas and solutions. With campuses and students across the entire globe we span the world, delivering innovation and educational excellence in business, engineering, design and the physical, social and life sciences. This email is generated from the Heriot-Watt University Group, which includes:

  1.  Heriot-Watt University, a Scottish charity registered under number SC000278
  2.  Heriot- Watt Services Limited (Oriam), Scotland's national performance centre for sport. Heriot-Watt Services Limited is a private limited company registered is Scotland with registered number SC271030 and registered office at Research & Enterprise Services Heriot-Watt University, Riccarton, Edinburgh, EH14 4AS.

The contents (including any attachments) are confidential. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system.

[mu4e-message-example (application/octet-stream, attachment)]

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

From: Rob Stewart <R.Stewart <at> hw.ac.uk>
To: 72771 <at> debbugs.gnu.org
Subject: Re: 31.0.50; shr html renderer throwing "Specified window is not
 displaying the current buffer"
Date: Fri, 23 Aug 2024 10:13:54 +0100

See the comment on the mu4e bug tracker:

Seems that Gnus no longer allows for offscreen rendering, since commit a876c4d7a17. In particular, the change in shr-indent, with font-at raising that error.

Using the old definition, it still works:

--8<---------------cut here---------------start------------->8---
(defun shr-indent ()
  (when (> shr-indentation 0)
    (if (not shr-use-fonts)
        (insert-char ?\s shr-indentation)
      (insert ?\s)
      (put-text-property (1- (point)) (point)
                         'display `(space :width (,shr-indentation))))))
--8<---------------cut here---------------end--------------->8---

https://github.com/djcb/mu/issues/2747#issuecomment-2306632897

Best wishes,

--
Rob

On 23/08/2024 at 09:15 Rob Stewart writes:

> When attempting to open the attached (anonymised) message with mm-text-html-renderer set to `shr`, I get this bracktrace:
>
> --8<---------------cut here---------------start------------->8---
> Debugger entered--Lisp error: (error "Specified window is not displaying the current buffer")
>   shr-indent()
>   shr-fill-line()
>   shr-fill-lines(13724 15455)
>   shr-insert-document((html ((xmlns:o . .))))
>   mm-shr((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   mm-inline-text-html((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   mm-display-inline((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   mm-display-part((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   gnus-mime-display-alternative(((#<buffer *mm*-410985> ("text/plain" (charset
> . "Windows-1252")) quoted-printable nil ("inline") nil nil nil) (#<buffer
> *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil
> nil nil nil)) nil nil 1)
>   gnus-mime-display-part((#("multipart/alternative" ...)))
>   gnus-display-mime(nil)
>   #f(compiled-function (&optional ihandles) #<bytecode -0xcb4ad9361861f2a>)()
>   gnus-article-prepare-display()
>   mu4e--view-render-buffer((:path ...))
>   mu4e-view((:path ...))
>   mu4e~headers-view-handler((:path ...))
> --8<---------------cut here---------------end--------------->8---
>
> I've been asked here:
>
> https://github.com/djcb/mu/issues/2747#issuecomment-2305245669
>
> to report this as an Emacs bug/incompatibility.
>
> I'm using Emacs build 3d1d4f109ed4115256a08c74eeb704259d91c9f4 (21 August 2024).
>
> Best wishes,
________________________________

Founded in 1821, Heriot-Watt is a leader in ideas and solutions. With campuses and students across the entire globe we span the world, delivering innovation and educational excellence in business, engineering, design and the physical, social and life sciences. This email is generated from the Heriot-Watt University Group, which includes:

  1.  Heriot-Watt University, a Scottish charity registered under number SC000278
  2.  Heriot- Watt Services Limited (Oriam), Scotland's national performance centre for sport. Heriot-Watt Services Limited is a private limited company registered is Scotland with registered number SC271030 and registered office at Research & Enterprise Services Heriot-Watt University, Riccarton, Edinburgh, EH14 4AS.

The contents (including any attachments) are confidential. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rob Stewart <R.Stewart <at> hw.ac.uk>, Jim Porter <jporterbugs <at> gmail.com>
Cc: 72771 <at> debbugs.gnu.org
Subject: Re: bug#72771: 31.0.50;
 shr html renderer throwing "Specified window is not displaying the
 current buffer"
Date: Fri, 23 Aug 2024 16:12:28 +0300

> Date: Fri, 23 Aug 2024 09:15:52 +0100
> From:  Rob Stewart via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> When attempting to open the attached (anonymised) message with mm-text-html-renderer set to `shr`, I get this bracktrace:
> 
> --8<---------------cut here---------------start------------->8---
> Debugger entered--Lisp error: (error "Specified window is not displaying the current buffer")
>   shr-indent()
>   shr-fill-line()
>   shr-fill-lines(13724 15455)
>   shr-insert-document((html ((xmlns:o . .))))
>   mm-shr((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   mm-inline-text-html((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   mm-display-inline((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   mm-display-part((#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil))
>   gnus-mime-display-alternative(((#<buffer  *mm*-410985> ("text/plain" (charset . "Windows-1252")) quoted-printable nil ("inline") nil nil nil) (#<buffer  *mm*-655965> ("text/html" (charset . "Windows-1252")) quoted-printable nil nil nil nil nil)) nil nil 1)
>   gnus-mime-display-part((#("multipart/alternative" ...)))
>   gnus-display-mime(nil)
>   #f(compiled-function (&optional ihandles) #<bytecode -0xcb4ad9361861f2a>)()
>   gnus-article-prepare-display()
>   mu4e--view-render-buffer((:path ...))
>   mu4e-view((:path ...))
>   mu4e~headers-view-handler((:path ...))
> --8<---------------cut here---------------end--------------->8---
> 
> I've been asked here:
> 
> https://github.com/djcb/mu/issues/2747#issuecomment-2305245669
> 
> to report this as an Emacs bug/incompatibility.
> 
> I'm using Emacs build 3d1d4f109ed4115256a08c74eeb704259d91c9f4 (21 August 2024).

This is being discussed here:

  https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00788.html

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Rob Stewart <R.Stewart <at> hw.ac.uk>, 72771 <at> debbugs.gnu.org,
 Jim Porter <jporterbugs <at> gmail.com>
Subject: Re: bug#72771: 31.0.50; shr html renderer throwing "Specified
 window is not displaying the current buffer"
Date: Fri, 23 Aug 2024 19:10:05 +0200

Thanks for opening an issue Rob!

Eli Zaretskii <eliz <at> gnu.org> writes:

> This is being discussed here:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00788.html

(Will be traveling during the coming week, with limited time &
connectivity, so anyone should feel free to beat me to installing the
visual-wrap patch - AFAIU from the reported backtraces though, it won't
fix the issues that other folks are having)

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: Rob Stewart <R.Stewart <at> hw.ac.uk>, 72771 <at> debbugs.gnu.org
Subject: Re: bug#72771: 31.0.50; shr html renderer throwing "Specified window
 is not displaying the current buffer"
Date: Fri, 23 Aug 2024 15:39:00 -0700

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

On 8/23/2024 10:10 AM, Kévin Le Gouguec wrote:
> Thanks for opening an issue Rob!
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>> This is being discussed here:
>>
>>    https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00788.html
> 
> (Will be traveling during the coming week, with limited time &
> connectivity, so anyone should feel free to beat me to installing the
> visual-wrap patch - AFAIU from the reported backtraces though, it won't
> fix the issues that other folks are having)

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.)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
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 09:08:32 +0300

> 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)

Message #23 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 10:10:06 -0700

On 8/23/2024 11:08 PM, Eli Zaretskii wrote:
>> 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?

Close, it needs the "average width", since the goal is to make a pixel 
specification like "(1.23 . width)". Based on my reading of 
'calc_pixel_width_or_height' in xdisp.c, the average width is the value 
the display engine uses for the 'width' unit.

> And the patch solves the problem of font-at by pretending that the
> relevant text is displayed in the current window, is that correct?

Yep. I figure there's a very good chance that the text in question 
(which is already in the current buffer) will soon be displayed in the 
current window, or failing that, a different window in the same frame. 
So it seemed like an ok guess to me. (Also, even if we guess wrong, 
things should usually look fine; it would only fail with certain 
pathological fonts, and even then it would just be a slight visual 
misalignment.)

> Alternatives to the solution in the patch are:

Thanks for the suggestions. (I reordered the list below when replying.)

>   . 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...

>   . temporarily display the buffer in some window (if there is already
>     a window showing the buffer, use with-selected-window)

That could work, though I think it ends up being just as much code 
complexity as my current patch, and it might perform worse with all the 
temporary window-switching...

>   . 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.

In light of the above, I think what I have now might be the best way to 
do it for the time being, unless my comments above gave you another idea 
for an alternative. If not, do you have any objections to me merging 
this patch?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
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 22:01:05 +0300

> 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?

> >   . 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.

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);

> 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?

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)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
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: Sun, 25 Aug 2024 08:05:49 +0300

> Date: Sat, 24 Aug 2024 12:42:04 -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>
> 
> >> 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.

Message #35 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 23:11:46 -0700

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

On 8/24/2024 10:05 PM, Eli Zaretskii wrote:
> Again, the simplicity here is deceptive.

Since you seemed so unsure about my earlier patch, I figured I should be 
extra careful to think about whether there's a better way.

Previously, you'd suggested using 'string-pixel-width' using a few 
characters to compute an average width. After thinking about it, I 
realized that it's actually possible to get the real 
'font->average_width' value using 'string-pixel-width': just use a 
display spec!

  (string-pixel-width
   (propertize some-length-1-string 'display '(space :width 1)))

That works out nicely since then the only function I'm using to compute 
string widths in this code is 'string-pixel-width', so there's less risk 
of different functions having slightly different font handling.

As an added bonus, this new implementation is even simpler than the 
original code that prompted this bug. See attached.

>> Thanks for prompting me to re-read the manual on this. I'd
>> misinterpreted this passage in the documentation for 'query-font':
[snip]
> I don't see how this is different from the text we already have,
> sorry.

Here's another variation on the documentation that might be clearer?

"The average width of the font characters. Emacs uses this value when 
calculating text layout on display. If this is zero, Emacs uses
the value of space-width instead."

(Maybe this could cross reference the section on pixel specifications 
too, or some other documentation about text layout.)

If that doesn't seem any better, that's ok. I'll stop suggesting further 
variations. :)

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
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: Sun, 25 Aug 2024 09:22:55 +0300

> Date: Sat, 24 Aug 2024 23:11:46 -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>
> 
> Previously, you'd suggested using 'string-pixel-width' using a few 
> characters to compute an average width. After thinking about it, I 
> realized that it's actually possible to get the real 
> 'font->average_width' value using 'string-pixel-width': just use a 
> display spec!
> 
>    (string-pixel-width
>     (propertize some-length-1-string 'display '(space :width 1)))
> 
> That works out nicely since then the only function I'm using to compute 
> string widths in this code is 'string-pixel-width', so there's less risk 
> of different functions having slightly different font handling.

Good idea.

> >> Thanks for prompting me to re-read the manual on this. I'd
> >> misinterpreted this passage in the documentation for 'query-font':
> [snip]
> > I don't see how this is different from the text we already have,
> > sorry.
> 
> Here's another variation on the documentation that might be clearer?
> 
> "The average width of the font characters. Emacs uses this value when 
> calculating text layout on display. If this is zero, Emacs uses
> the value of space-width instead."

That's again exactly what the current text does, just broken into
sentences differently.

I'm sorry, I must understand what is it in the original text that
misled you, before I can consider any changes.

The updated patch LGTM, thanks.

Message #43 received at 72771-done <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, kevin.legouguec <at> gmail.com, 72771-done <at> debbugs.gnu.org
Subject: Re: bug#72771: 31.0.50; shr html renderer throwing "Specified window
 is not displaying the current buffer"
Date: Sun, 25 Aug 2024 10:18:27 -0700

On 8/24/2024 11:22 PM, Eli Zaretskii wrote:
> That's again exactly what the current text does, just broken into
> sentences differently.
> 
> I'm sorry, I must understand what is it in the original text that
> misled you, before I can consider any changes.

Reordering the info was all I was trying to do. As I was reading it 
initially I thought that, "If this is zero, Emacs uses the value of 
space-width instead," referred back to the value of average-width, 
rather than forward to, "when it calculates text layout on display," 
since I hadn't read that far yet.

I was probably just reading too quickly, since the last phrase didn't 
make me reevaluate my incorrect understanding. But I thought I'd reorder 
things so it was harder to make that error.

Still, I understand it now and I'm not sure whether others would have 
the same issue, so I don't know if we need to worry about this .

> The updated patch LGTM, thanks.

Thanks for checking again. Pushed to the master branch as 55aad592e17, 
and closing this bug.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: R.Stewart <at> hw.ac.uk, kevin.legouguec <at> gmail.com, 72771-done <at> debbugs.gnu.org
Subject: Re: bug#72771: 31.0.50; shr html renderer throwing "Specified window
 is not displaying the current buffer"
Date: Sun, 25 Aug 2024 20:49:13 +0300

> Date: Sun, 25 Aug 2024 10:18:27 -0700
> Cc: R.Stewart <at> hw.ac.uk, 72771-done <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > I'm sorry, I must understand what is it in the original text that
> > misled you, before I can consider any changes.
> 
> Reordering the info was all I was trying to do. As I was reading it 
> initially I thought that, "If this is zero, Emacs uses the value of 
> space-width instead," referred back to the value of average-width, 
> rather than forward to, "when it calculates text layout on display," 
> since I hadn't read that far yet.
> 
> I was probably just reading too quickly, since the last phrase didn't 
> make me reevaluate my incorrect understanding. But I thought I'd reorder 
> things so it was harder to make that error.

Now I see the problem, thanks.  I've now changed the text to say

  The average width of the font characters.  Emacs uses this for
  calculating text layout on display; if the value of @var{average-width}
  is zero, Emacs uses the value of @var{space-width} instead for those
  purposes.

Message #49 received at 72771-done <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-done <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: Sun, 25 Aug 2024 11:51:07 -0700

On 8/25/2024 10:49 AM, Eli Zaretskii wrote:
> Now I see the problem, thanks.  I've now changed the text to say
> 
>    The average width of the font characters.  Emacs uses this for
>    calculating text layout on display; if the value of @var{average-width}
>    is zero, Emacs uses the value of @var{space-width} instead for those
>    purposes.

That version sounds great to me, thanks.

Previous Next

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