From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <868qwlmbte.fsf@gnu.org> References: <875xrrr6x3.fsf@hw.ac.uk> <861q2fqt6r.fsf@gnu.org> <875xrrcgia.fsf@gmail.com> <3482d616-8a1c-d458-8da4-1b9d12ff32c5@gmail.com> <867cc6pi5b.fsf@gnu.org> <86ed6dn3ta.fsf@gnu.org> <5ae9ebbe-924a-5f8a-6630-12f009c96629@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18325"; mail-complaints-to="usenet@ciao.gmane.io" Cc: R.Stewart@hw.ac.uk, 72771@debbugs.gnu.org, kevin.legouguec@gmail.com To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 25 07:06:31 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1si5SQ-0004Zf-Gt for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Aug 2024 07:06:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1si5SA-0000pm-JC; Sun, 25 Aug 2024 01:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1si5S9-0000p8-9U for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 01:06:13 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1si5S8-0008JG-VW for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 01:06:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=BNjXHGgiUIMaxiqJfhPFaU3MG+aZyXdW2iLgt/w0ZjA=; b=Q4gWA5Z94KCdRj2bY3YoQD1GaFzrCO/NnqYmXwHKb99/m9LinfkuEFF55s6DhVWLz5cTKvBosJjH9fuyFCTz659C7y6t+cMvUJX/ucKOph22o9KVj9Y3mfyvaTBGQkWTP9Q74i4rYf00CUyeR1e5VfCEEgErmbr/em4ubi+xFiHp+r50+l5zTRszRLGbbyBnOkQNUfCBTkdvANWQMKCGaUlJ9A6RlhazcHfyxGV00GNN8qfisrlZqbZx2l4KJquWtGlTKWc8RlGGIuOeC57AGqQdlJlewRKYhnPj+HCcWYf8Atg6pPWKd36gHIHdUOztv4eGIGOKhFmVGM+6Ug6bDQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1si5Sw-00089d-Cm for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 01:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 05:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72771 X-GNU-PR-Package: emacs Original-Received: via spool by 72771-submit@debbugs.gnu.org id=B72771.172456240931302 (code B ref 72771); Sun, 25 Aug 2024 05:07:02 +0000 Original-Received: (at 72771) by debbugs.gnu.org; 25 Aug 2024 05:06:49 +0000 Original-Received: from localhost ([127.0.0.1]:42073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1si5Sj-00088o-Bk for submit@debbugs.gnu.org; Sun, 25 Aug 2024 01:06:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1si5Sh-00088Z-Hq for 72771@debbugs.gnu.org; Sun, 25 Aug 2024 01:06:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1si5Ro-0008If-7K; Sun, 25 Aug 2024 01:05:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BNjXHGgiUIMaxiqJfhPFaU3MG+aZyXdW2iLgt/w0ZjA=; b=YpQv3MijAt3m F/RAFEkkGrnCpiNji+0GL8jkgx9jdF2N3yvFzQLN2NiJTNmMFzCg7Qvk7V9a8HCnJQonzvzpJVfYe /oYDbwdzLeOPW5v2G4gRjZGIWbt4LBc0QLHt7A0Wc9G1nvzPFC/xBKpR/kwGV0gWbp/OGA8mVBM2r VlA2crIHzrjJLiH/BpMALHRmcXDilTGISKM/TfEmJuZ5KSiX5I7pnrbVsgkB1Q7pzJo21F272roaU PK4KG0R0kjmK7FXFWKCh1xSoF/EVJGBgrf2IZ1VH7KWggV22zf8fQ7pYaJ2jJXeXaNe7dLg9md+Z+ oujpPmgSVcTWE8+cz+W12Q==; In-Reply-To: <5ae9ebbe-924a-5f8a-6630-12f009c96629@gmail.com> (message from Jim Porter on Sat, 24 Aug 2024 12:42:04 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:290714 Archived-At: > 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 > > >> 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). Fine by me.