unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: R.Stewart@hw.ac.uk, 72771@debbugs.gnu.org, kevin.legouguec@gmail.com
Subject: 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	[thread overview]
Message-ID: <5ae9ebbe-924a-5f8a-6630-12f009c96629@gmail.com> (raw)
In-Reply-To: <86ed6dn3ta.fsf@gnu.org>

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


  reply	other threads:[~2024-08-24 19:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-23  8:15 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
2024-08-23  9:13 ` Rob Stewart via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-23 13:12 ` Eli Zaretskii
2024-08-23 17:10   ` Kévin Le Gouguec
2024-08-23 22:39     ` Jim Porter
2024-08-24  6:08       ` Eli Zaretskii
2024-08-24 17:10         ` Jim Porter
2024-08-24 19:01           ` Eli Zaretskii
2024-08-24 19:42             ` Jim Porter [this message]
2024-08-25  5:05               ` Eli Zaretskii
2024-08-25  6:11                 ` Jim Porter
2024-08-25  6:22                   ` Eli Zaretskii
2024-08-25 17:18                     ` Jim Porter
2024-08-25 17:49                       ` Eli Zaretskii
2024-08-25 18:51                         ` Jim Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ae9ebbe-924a-5f8a-6630-12f009c96629@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=72771@debbugs.gnu.org \
    --cc=R.Stewart@hw.ac.uk \
    --cc=eliz@gnu.org \
    --cc=kevin.legouguec@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).