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

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

[Rob Stewart via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]

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.

[-- Attachment #2: mu4e-message-example --]
[-- Type: application/octet-stream, Size: 12509 bytes --]

Received: from LO9P302MB1718.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:3fe::18)
 by LO0P302MB0321.GBRP302.PROD.OUTLOOK.COM with HTTPS; Thu, 22 Aug 2024
 13:45:48 +0000
Received: from CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM (2603:10a6:400:224::5)
 by LO9P302MB1718.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:3fe::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.21; Thu, 22 Aug
 2024 13:45:47 +0000
Received: from CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM
 ([fe80::4cdc:4d70:def6:7850]) by CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM
 ([fe80::4cdc:4d70:def6:7850%3]) with mapi id 15.20.7897.014; Thu, 22 Aug 2024
 13:45:47 +0000
From: "ANON" <ANON1@example.com>
To: "ANON" <ANON2@example.com>
CC: "ANON" <ANON3@example.com>, "ANON"
	<ANON4@example.com>
Subject: Re: ANON SUBJECT
Thread-Topic: ANON SUBJECT
Thread-Index: AQHa8bVP2SfW3AN2f0OGBQIpAxWoIbIzS5ZggAAC+AiAAACa0g==
Date: Thu, 22 Aug 2024 14:45:47 +0100
Message-ID: 
	<CWLP302MB0024B5E060A94B620926E06FD98F2@CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM>
References: 
	<CWLP302MB002470D028C7435E4645AD4ED9832@CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM>
 <CWLP302MB0024D62DA21BF4776FA9761ED98F2@CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM>
 <LO2P302MB00693411F7603E932278E45AA28F2@LO2P302MB0069.GBRP302.PROD.OUTLOOK.COM>
In-Reply-To: 
	<LO2P302MB00693411F7603E932278E45AA28F2@LO2P302MB0069.GBRP302.PROD.OUTLOOK.COM>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM
X-MS-Has-Attach: 
X-MS-Exchange-Organization-Network-Message-Id: 
	22bf1084-b138-4e94-94fe-08dcc2b0ba13
X-MS-Exchange-Organization-SCL: 1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=example.com;
x-ms-publictraffictype: Email
msip_labels: 
x-forefront-antispam-report: 
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(41050700001);DIR:INT;
x-microsoft-antispam: BCL:0;ARA:13230040|366016|41050700001;
x-ms-traffictypediagnostic: 
	CWLP302MB0024:EE_|LO9P302MB1718:EE_|LO0P302MB0321:EE_
x-ms-office365-filtering-correlation-id: 22bf1084-b138-4e94-94fe-08dcc2b0ba13
x-ms-exchange-transport-endtoendlatency: 00:00:00.9281003
x-ms-exchange-processed-by-bccfoldering: 15.20.7897.007
x-ms-exchange-crosstenant-originalarrivaltime: 22 Aug 2024 13:45:47.1572 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 6c425ff2-6865-42df-a4db-8e6af634813d
x-ms-exchange-crosstenant-network-message-id: 
	22bf1084-b138-4e94-94fe-08dcc2b0ba13
x-ms-exchange-transport-crosstenantheadersstamped: LO9P302MB1718
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: 
	DQd+K+OX9D8Kba9q8T3jmFMf/OshYh3N7hoU6pgySxv3Len4pePeiYSxzmApArZ3
x-ms-exchange-crosstenant-authas: Internal
x-ms-exchange-crosstenant-authsource: CWLP302MB0024.GBRP302.PROD.OUTLOOK.COM
X-Microsoft-Antispam-Mailbox-Delivery: 
	ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(425001)(930097)(140003);
X-Microsoft-Antispam-Message-Info: 
	H5BxP7MwKXwunQK4TgqBSfA/3tvPvYQW8yQp9bJkxz2PJbjIMB7MngI0lUalUemVqIFdKVhwKlswBMftyen76pZTyrf+hvWP8m3A2C0I/AQl5oDN3jWbipKWzZAVTQTFcmwrCZXA/ulW3ibSOskD6mlO6YR16F+vE1wx6CT9aCyEToXtFQMajQ3+xc/ZHW50ARHFSvyV0zn3RAyZCeufUSQkYClPx2+djndxKYU4Tcz9odVpANloGMhDhLkrsuTNaV41FZjxnWKBOlFDsnbOZGwjKLrse2F0ur87+VC+On0n4x84Pt3xOfJ9bLQNhhJ9nAisH1fJzK2YawLagI8kA5dtovPmF2si0bB1apSpBBka2aYQB25Z3ZsZ16XbjcbC+26S48ctV5gtibntfF/rX7kx90nI6mrQQXS//kc0IIjImKNk5ljUResRmM+/LKBHMSd8hymz7DtbBp/TRLlDBYE1+zVqard1HfXZqkobznTcFixXS1YINTQvlWZf6UX62yaTYKQbnumkwmAAw7fdw2oFDWKZo4PIKfbjNnK0wSX58omLIavPHtO3Q0sTb/0KLhOPu51BAj78ygNriwPqHdCsdoTXPLQA83e4F1Za0sXsXXkJ3669sG+MCaVl8DerG3GYw+hUtTLPztF6TpCEllKkhqG5chF0WoWbgKRJcGEiGwvweO59d484cKrKdIdIGmnoO06tAHFV1hqyaRc2BKZLdmMQIk8NwdiRU8U8hcz7Y0xACiS5ppb8nE07PC+uDiDVl/kVUVCAp2Sw4ntpY0EiSxGxxYoBsQVYuPbhO/RjIosI5AtDo3Z0gNssVYmFYGkEyQNRjnZmi6QrvXQYUA==
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Aptos;
	panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:12.0pt;
	font-family:"Aptos",sans-serif;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
	{mso-style-name:x_msonormal;
	margin:0cm;
	font-size:11.0pt;
	font-family:"Aptos",sans-serif;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	mso-ligatures:none;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1686131080;
	mso-list-template-ids:295489012;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US">Haha =96 no worries, actually partly my fault as I was talking abou=
t this with Jeevani yesterday!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US">I still need to tidy one thing (Tom=92s picture), so I will fix tha=
t in version 1.01.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US">Thanks for spotting this.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US">Cheers.S.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US"><o:p>&nbsp;</o:p></span></p>
<div id=3D"mail-editor-reference-message-container">
<div>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=
or:black">From:
</span></b><span style=3D"color:black">ANON &lt;ANON2@example.com&gt;=
<br>
<b>Date: </b>Thursday, 22 August 2024 at 14:42<br>
<b>To: </b>ANON &lt;ANON1@example.com&gt;<br>
<b>Cc: </b>ANON &lt;ANON3@example.com&gt;, ANON &lt;ANON4@example.com&gt;<br>
<b>Subject: </b>Re: ANON SUBJECT<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">REDACTED.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p>&nbsp;</o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">Cheers,<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">Mike<o:p></o:p></span></=
p>
</div>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"0" width=3D"100%" align=3D"center">
</div>
<div id=3D"divRplyFwdMsg">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;color:black">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:black"> ANON &lt;ANON1@example.com&gt;<br>
<b>Sent:</b> 22 August 2024 14:39<br>
<b>To:</b> ANONYMISED@example.com &lt;ANONYMISED2@example.com.uk&gt;<br>
<b>Cc:</b> ANON &lt;ANON5@example.com&gt;; ANON=
 &lt;ANON6@example.com&gt;<br>
<b>Subject:</b> Re: ANON SUBECT</span> <o:p></o:p=
></p>
<div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=3D"xmsonormal">Hi all =96 <o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">REDACTED.<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">Cheers, <o:p></o:p></p>
<p class=3D"xmsonormal">S.<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<div id=3D"x_mail-editor-reference-message-container">
<div>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"xmsonormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fo=
nt-size:12.0pt;color:black">From:
</span></b><span style=3D"font-size:12.0pt;color:black">ANON &l=
t;ANON1@example.com&gt;<br>
<b>Date: </b>Monday, 19 August 2024 at 08:00<br>
<b>To: </b>ANON@example.com &lt;ANON@example.com&gt;<br>
<b>Cc: </b>ANON &lt;ANON6@example.com&gt;, ANON=
 &lt;ANON7@example.com&gt;<br>
<b>Subject: </b>ANON Subject</span><o:p></o:p></p>
</div>
<div>
<p class=3D"xmsonormal">Hi all =96 <o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">REDACTED
<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">REDACTED.<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">REDACTED!<o:p></o:p></p>
<p class=3D"xmsonormal">&nbsp;<o:p></o:p></p>
<p class=3D"xmsonormal">Cheers, ANON.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"0" width=3D"100%" align=3D"center">
</div>
<p><span style=3D"font-size:8.0pt;font-family:&quot;Arial&quot;,sans-serif"=
>Founded in 1821, Heriot-Watt is a leader in ideas and solutions. With camp=
uses and students across the entire globe we span the world, delivering inn=
ovation 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:<o:p></=
o:p></span></p>
<ol start=3D"1" type=3D"1">
<li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=
alt:auto;mso-list:l0 level1 lfo1">
<span style=3D"font-size:8.0pt;font-family:&quot;Arial&quot;,sans-serif">He=
riot-Watt University, a Scottish charity registered under number SC000278<o=
:p></o:p></span></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:au=
to;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style=3D"font-size:8.0pt;font-family:&quot;Arial&quot;,sans-serif">He=
riot- Watt Services Limited (Oriam), Scotland's national performance centre=
 for sport. Heriot-Watt Services Limited is a private limited company regis=
tered is Scotland with registered number SC271030
 and registered office at Research &amp; Enterprise Services Heriot-Watt Un=
iversity, Riccarton, Edinburgh, EH14 4AS.<o:p></o:p></span></li></ol>
<p><span style=3D"font-size:8.0pt;font-family:&quot;Arial&quot;,sans-serif"=
>The contents (including any attachments) are confidential. If you are not =
the intended recipient of this e-mail, any disclosure, copying, distributio=
n or use of its contents is strictly prohibited,
 and you should please notify the sender immediately and then delete it (in=
cluding any attachments) from your system.<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

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

[Rob Stewart via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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

[Eli Zaretskii]

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

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

[Kévin Le Gouguec]

Thanks for opening an issue Rob!

Eli Zaretskii <eliz@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)

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

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

On 8/23/2024 10:10 AM, Kévin Le Gouguec wrote:
> Thanks for opening an issue Rob!
> 
> Eli Zaretskii <eliz@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.)

[-- Attachment #2: 0001-Improve-computation-of-indent-depth-in-SHR-and-visua.patch --]
[-- Type: text/plain, Size: 3003 bytes --]

From 5cd39589ebd47ccc8f53b8921fadd566df316d21 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Fri, 23 Aug 2024 15:11:24 -0700
Subject: [PATCH] Improve computation of indent depth in SHR and
 'visual-wrap-prefix-mode'

This method gets the font that would be used for the current window for
the text in question.  That way, there are no problems if the current
buffer isn't being displayed in a window.

* lisp/net/shr.el (shr-indent):
* lisp/visual-wrap.el (visual-wrap--content-prefix): Fix getting the
font when the buffer isn't displayed in a window.
(visual-wrap-fill-context-prefix): Fix indentation.
---
 lisp/net/shr.el     | 12 +++++++-----
 lisp/visual-wrap.el |  5 +++--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index b9ac9f0c8c0..a55c97b1349 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1057,11 +1057,13 @@ shr-indent
          ;; of the current face, like (N . width).  That way, the
          ;; indentation is calculated correctly when using
          ;; `text-scale-adjust'.
-         `(space :width (,(if-let ((font (font-at (1- (point))))
-                                   (info (query-font font)))
-                              (/ (float shr-indentation) (aref info 7))
-                            shr-indentation)
-                         . width))))
+         `(space :width
+                 (,(if-let ((text (buffer-substring (1- (point)) (point)))
+                            (font (font-at 0 nil text))
+                            (info (query-font font)))
+                       (/ (float shr-indentation) (aref info 7))
+                     shr-indentation)
+                  . width))))
       (put-text-property start (+ (point) prefix)
                          'shr-prefix-length (+ prefix (- (point) start))))))
 
diff --git a/lisp/visual-wrap.el b/lisp/visual-wrap.el
index 902a9e41c5e..52ac39513be 100644
--- a/lisp/visual-wrap.el
+++ b/lisp/visual-wrap.el
@@ -164,7 +164,8 @@ visual-wrap--content-prefix
     ;; width of the first-line prefix in canonical-width characters.
     ;; This is useful if the first-line prefix uses some very-wide
     ;; characters.
-    (if-let ((font (font-at position))
+    (if-let ((text (buffer-substring position (1+ position)))
+             (font (font-at 0 nil text))
              (info (query-font font)))
         (max (string-width prefix)
              (ceiling (string-pixel-width prefix (current-buffer))
@@ -189,7 +190,7 @@ visual-wrap-fill-context-prefix
           ;; make much sense (and is positively harmful in
           ;; taskpaper-mode where paragraph-start matches everything).
           (or (let ((paragraph-start regexp-unmatchable))
-                    (fill-context-prefix beg end))
+                (fill-context-prefix beg end))
                   ;; Note: fill-context-prefix may return nil; See:
                   ;; http://article.gmane.org/gmane.emacs.devel/156285
               ""))
-- 
2.25.1

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

[Eli Zaretskii]

> Date: Fri, 23 Aug 2024 15:39:00 -0700
> Cc: Rob Stewart <R.Stewart@hw.ac.uk>, 72771@debbugs.gnu.org
> From: Jim Porter <jporterbugs@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)

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

[Jim Porter]

On 8/23/2024 11:08 PM, Eli Zaretskii wrote:
>> Date: Fri, 23 Aug 2024 15:39:00 -0700
>> Cc: Rob Stewart <R.Stewart@hw.ac.uk>, 72771@debbugs.gnu.org
>> From: Jim Porter <jporterbugs@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?

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2024 10:10:06 -0700
> Cc: R.Stewart@hw.ac.uk, 72771@debbugs.gnu.org, kevin.legouguec@gmail.com
> From: Jim Porter <jporterbugs@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?

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

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 3663 bytes --]

On 8/24/2024 12:01 PM, Eli Zaretskii wrote:
>> Date: Sat, 24 Aug 2024 10:10:06 -0700
>> Cc: R.Stewart@hw.ac.uk, 72771@debbugs.gnu.org, kevin.legouguec@gmail.com
>> From: Jim Porter <jporterbugs@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...

[-- Attachment #2: 0001-Improve-computation-of-indent-depth-in-SHR-and-visua.patch --]
[-- Type: text/plain, Size: 3648 bytes --]

From 0ef908e34e7a75e84dcadb4b09d583faacbd2bba Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Fri, 23 Aug 2024 15:11:24 -0700
Subject: [PATCH] Improve computation of indent depth in SHR and
 'visual-wrap-prefix-mode'

This method gets the font that would be used for the current window for
the text in question.  That way, there are no problems if the current
buffer isn't being displayed in a window.

* lisp/net/shr.el (shr-indent):
* lisp/visual-wrap.el (visual-wrap--content-prefix): Fix getting the
font when the buffer isn't displayed in a window.
(visual-wrap-fill-context-prefix): Fix indentation.
---
 lisp/net/shr.el     | 15 ++++++++++-----
 lisp/visual-wrap.el | 12 ++++++++----
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index b9ac9f0c8c0..1cbd9a0eaf5 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1057,11 +1057,16 @@ shr-indent
          ;; of the current face, like (N . width).  That way, the
          ;; indentation is calculated correctly when using
          ;; `text-scale-adjust'.
-         `(space :width (,(if-let ((font (font-at (1- (point))))
-                                   (info (query-font font)))
-                              (/ (float shr-indentation) (aref info 7))
-                            shr-indentation)
-                         . width))))
+         `(space :width
+                 (,(if-let ((text (buffer-substring (1- (point)) (point)))
+                            (font (font-at 0 nil text))
+                            (info (query-font font))
+                            (avg-width (if (/= (aref info 7) 0)
+                                           (aref info 7)
+                                         (aref info 6))))
+                       (/ (float shr-indentation) avg-width)
+                     shr-indentation)
+                  . width))))
       (put-text-property start (+ (point) prefix)
                          'shr-prefix-length (+ prefix (- (point) start))))))
 
diff --git a/lisp/visual-wrap.el b/lisp/visual-wrap.el
index 902a9e41c5e..d0c87fd6e9e 100644
--- a/lisp/visual-wrap.el
+++ b/lisp/visual-wrap.el
@@ -164,11 +164,15 @@ visual-wrap--content-prefix
     ;; width of the first-line prefix in canonical-width characters.
     ;; This is useful if the first-line prefix uses some very-wide
     ;; characters.
-    (if-let ((font (font-at position))
-             (info (query-font font)))
+    (if-let ((text (buffer-substring position (1+ position)))
+             (font (font-at 0 nil text))
+             (info (query-font font))
+             (avg-width (if (/= (aref info 7) 0)
+                            (aref info 7)
+                          (aref info 6))))
         (max (string-width prefix)
              (ceiling (string-pixel-width prefix (current-buffer))
-                      (aref info 7)))
+                      avg-width))
       ;; We couldn't get the font, so we're in a terminal and
       ;; `string-pixel-width' is really returning the number of columns.
       ;; (This is different from `string-width', since that doesn't
@@ -189,7 +193,7 @@ visual-wrap-fill-context-prefix
           ;; make much sense (and is positively harmful in
           ;; taskpaper-mode where paragraph-start matches everything).
           (or (let ((paragraph-start regexp-unmatchable))
-                    (fill-context-prefix beg end))
+                (fill-context-prefix beg end))
                   ;; Note: fill-context-prefix may return nil; See:
                   ;; http://article.gmane.org/gmane.emacs.devel/156285
               ""))
-- 
2.25.1

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

[Eli Zaretskii]

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

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

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

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

[-- Attachment #2: 0001-Improve-computation-of-indent-depth-in-SHR-and-visua.patch --]
[-- Type: text/plain, Size: 4429 bytes --]

From 75805447a60e402adf0ff2496260b27ffe412b99 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Fri, 23 Aug 2024 15:11:24 -0700
Subject: [PATCH] Improve computation of indent depth in SHR and
 'visual-wrap-prefix-mode'

Now, we get the average-width of the current font using
'string-pixel-width' and a specified space display spec, which doesn't
require the buffer to be displayed in a window (bug#72771).

* lisp/net/shr.el (shr-indent):
* lisp/visual-wrap.el (visual-wrap--content-prefix): Fix getting the
font when the buffer isn't displayed in a window.
(visual-wrap-fill-context-prefix): Fix indentation.
---
 lisp/net/shr.el     | 22 +++++++++++-----------
 lisp/visual-wrap.el | 20 +++++++-------------
 2 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index b9ac9f0c8c0..cd0e482aee7 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1051,17 +1051,17 @@ shr-indent
       (if (not shr-use-fonts)
           (insert-char ?\s shr-indentation)
         (insert ?\s)
-        (put-text-property
-         (1- (point)) (point) 'display
-         ;; Set the specified space width in terms of the default width
-         ;; of the current face, like (N . width).  That way, the
-         ;; indentation is calculated correctly when using
-         ;; `text-scale-adjust'.
-         `(space :width (,(if-let ((font (font-at (1- (point))))
-                                   (info (query-font font)))
-                              (/ (float shr-indentation) (aref info 7))
-                            shr-indentation)
-                         . width))))
+        ;; Set the specified space width in units of the average-width
+        ;; of the current font, like (N . width).  That way, the
+        ;; indentation is calculated correctly when using
+        ;; `text-scale-adjust'.
+        (let ((avg-space (propertize (buffer-substring (1- (point)) (point))
+                                     'display '(space :width 1))))
+          (put-text-property
+           (1- (point)) (point) 'display
+           `(space :width (,(/ (float shr-indentation)
+                               (string-pixel-width avg-space (current-buffer)))
+                           . width)))))
       (put-text-property start (+ (point) prefix)
                          'shr-prefix-length (+ prefix (- (point) start))))))
 
diff --git a/lisp/visual-wrap.el b/lisp/visual-wrap.el
index 902a9e41c5e..76276c0f474 100644
--- a/lisp/visual-wrap.el
+++ b/lisp/visual-wrap.el
@@ -160,20 +160,14 @@ visual-wrap--content-prefix
     prefix)
    (t
     ;; Otherwise, we want the prefix to be whitespace of the same width
-    ;; as the first-line prefix.  If possible, compute the real pixel
-    ;; width of the first-line prefix in canonical-width characters.
-    ;; This is useful if the first-line prefix uses some very-wide
-    ;; characters.
-    (if-let ((font (font-at position))
-             (info (query-font font)))
+    ;; as the first-line prefix.  We want to return an integer width (in
+    ;; units of the font's average-width) large enough to fit the
+    ;; first-line prefix.
+    (let ((avg-space (propertize (buffer-substring position (1+ position))
+                                 'display '(space :width 1))))
         (max (string-width prefix)
              (ceiling (string-pixel-width prefix (current-buffer))
-                      (aref info 7)))
-      ;; We couldn't get the font, so we're in a terminal and
-      ;; `string-pixel-width' is really returning the number of columns.
-      ;; (This is different from `string-width', since that doesn't
-      ;; respect specified spaces.)
-      (string-pixel-width prefix)))))
+                      (string-pixel-width avg-space (current-buffer))))))))
 
 (defun visual-wrap-fill-context-prefix (beg end)
   "Compute visual wrap prefix from text between BEG and END.
@@ -189,7 +183,7 @@ visual-wrap-fill-context-prefix
           ;; make much sense (and is positively harmful in
           ;; taskpaper-mode where paragraph-start matches everything).
           (or (let ((paragraph-start regexp-unmatchable))
-                    (fill-context-prefix beg end))
+                (fill-context-prefix beg end))
                   ;; Note: fill-context-prefix may return nil; See:
                   ;; http://article.gmane.org/gmane.emacs.devel/156285
               ""))
-- 
2.25.1

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2024 23:11:46 -0700
> Cc: R.Stewart@hw.ac.uk, 72771@debbugs.gnu.org, kevin.legouguec@gmail.com
> From: Jim Porter <jporterbugs@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.

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

[Jim Porter]

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.

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

[Eli Zaretskii]

> Date: Sun, 25 Aug 2024 10:18:27 -0700
> Cc: R.Stewart@hw.ac.uk, 72771-done@debbugs.gnu.org, kevin.legouguec@gmail.com
> From: Jim Porter <jporterbugs@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.

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

[Jim Porter]

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.