GNU bug report logs - #76519
30.1; Unexpected Results from window-text-pixel-size

Previous Next

Full log

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

From: AKIYAMA Kouhei <misohena <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76519 <at> debbugs.gnu.org
Subject: Re: bug#76519: 30.1; Unexpected Results from window-text-pixel-size
Date: Tue, 25 Feb 2025 20:24:07 +0900

Thank you for your response.

> > * Issue 1: Zero Width Returned in Certain Cases
> >
> > Depending on the values of `header-line-format` and `truncate-lines`,
> > `window-text-pixel-size` sometimes returns a width of zero.
>
> This issue is hard to fix, and I decided not to fix it. Lisp programs
> that use window-text-pixel-size should make sure the window used for
> measuring the text dimensions doesn't have any non-trivial features
> that affect the result, like line-truncation and header-line, turned
> on, or should turn them off around the call to window-text-pixel-size.
> Basically, any use of window-text-pixel-size when the buffer is not
> already shown in the window is problematic.

Understood.

In the first place, adjusting the buffer based on information
belonging to the view, such as windows and frames, is not ideal. If we
consider the case where a single buffer is displayed in multiple
windows or frames, it is clear that issues may arise. In practice,
perfection is not necessary, so some degree of compromise can be
accepted.

It seems better to update the buffer layout after it has been displayed.

> By the way, is there any reason you didn't use string-pixel-width
> instead? Or does it also have problems in this case?

The reason I did not use `string-pixel-width` is that I wanted to
measure the width of text that includes icons and thumbnail images
displayed via overlays (using the `after-string` and `before-string`
properties). While the test case used a temporary buffer, in reality,
the measurement was performed in a `dired-mode` buffer, and the timing
was within `dired-after-readin-hook` (after `nerd-icons-dired` had
added icons).

The issue I encountered was that, when `which-function-mode` was
enabled, the detailed information I forcibly displayed on the right
side of filenames would sometimes shift irregularly. Upon
investigation, I found that the issue was not limited to
`which-function-mode` but occurred whenever `header-line-format` was
used. The overlay icons were not a necessary condition for the issue,
but the `truncate-lines` setting in `dired` was relevant. However, not
all lines were affected, so there might be other conditions
involved. I have not tested `string-pixel-width`.

By the way, while looking at the manual, I noticed that the arguments
of the `buffer-text-pixel-size` function differ between the manual and
Emacs itself.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Size-of-Displayed-Text.html#index-buffer_002dtext_002dpixel_002dsize

  Function: buffer-text-pixel-size &optional buffer-or-name window
from to x-limit y-limit

  (buffer-text-pixel-size &optional BUFFER-OR-NAME WINDOW X-LIMIT Y-LIMIT)

> > * Issue 2: Negative Width Returned When Full-Width Characters Are Present
> >
> > If the buffer contains full-width characters, `window-text-pixel-size`
> > sometimes returns negative widths. This can be reproduced as follows:
>
> This was due to a stupid typo in the code, and is now fixed on the
> release branch (to be merged to master in a few days).

You've already fixed it? Amazing!
Thank you very much!

--
# This email was machine-translated from Japanese.
AKIYAMA Kouhei

Previous Next

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