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

Previous Next

Package: emacs;

Reported by: AKIYAMA Kouhei <misohena <at> gmail.com>

Date: Mon, 24 Feb 2025 07:50:02 UTC

Severity: normal

Found in version 30.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: AKIYAMA Kouhei <misohena <at> gmail.com>
Cc: 76519 <at> debbugs.gnu.org
Subject: bug#76519: 30.1; Unexpected Results from window-text-pixel-size
Date: Mon, 24 Feb 2025 21:29:47 +0200
> From: AKIYAMA Kouhei <misohena <at> gmail.com>
> Date: Mon, 24 Feb 2025 16:16:45 +0900
> 
> 
> * 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 can
> be reproduced as follows:
> 
> ;; --------------------------------------------------------
> ;; 1. Display the header line in the scratch buffer.
> (setq header-line-format "header")
> 
> ;; 2. Evaluate the following code in the scratch buffer:
> (require 'cl-lib)
> (with-temp-buffer
>   ;; Set buffer-local variables:
>   (setq truncate-lines t) ;; Without this, the problem will not occur
>   ;; (setq header-line-format "") ;; If uncomment this, the problem will not occur
> 
>   ;; Insert text
>   (insert "  -rw-rw-rw-  1 ***** none  8541546 18-02-01 17:43 01 - test test test test test.mp3
>   -rw-rw-rw-  1 ***** none 10519534 18-02-01 17:42 01 - test test test.mp3
> ")
> 
>   ;; Get width before file names
>   (save-window-excursion ;; Same method as `shr-pixel-column'
>     (set-window-dedicated-p nil nil)
>     (set-window-buffer nil (current-buffer))
> 
>     (goto-char (point-min))
>     (cl-loop while (re-search-forward "01 - " nil t)
>              collect (window-text-pixel-size
>                       nil
>                       (line-beginning-position)
>                       (match-beginning 0) 100000))))
> 
> ;; Result:
> ((408 . 16) (0 . 16))
> 
> ;; Expected
> ((408 . 16) (408 . 16))
> ;; --------------------------------------------------------

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.

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

> * 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 stupid typo in the code, and is now fixed on the
release branch (to be merged to master in a few days).

Thanks.




This bug report was last modified 129 days ago.

Previous Next


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