From unknown Mon Aug 11 12:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76519: 30.1; Unexpected Results from window-text-pixel-size Resent-From: AKIYAMA Kouhei Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Feb 2025 07:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 76519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 76519@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174038335125031 (code B ref -1); Mon, 24 Feb 2025 07:50:02 +0000 Received: (at submit) by debbugs.gnu.org; 24 Feb 2025 07:49:11 +0000 Received: from localhost ([127.0.0.1]:38273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmTDC-0006Vf-AW for submit@debbugs.gnu.org; Mon, 24 Feb 2025 02:49:11 -0500 Received: from lists.gnu.org ([2001:470:142::17]:36826) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmSiB-00052h-Oc for submit@debbugs.gnu.org; Mon, 24 Feb 2025 02:17:08 -0500 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 1tmSi4-00048i-MZ for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2025 02:17:00 -0500 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tmSi2-00023k-Jl for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2025 02:17:00 -0500 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-22128b7d587so75204905ad.3 for ; Sun, 23 Feb 2025 23:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740381414; x=1740986214; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=eS5eqM+Cjh8hMR+i/eN58WnJ3+4iziz4nMKxMrjajbM=; b=RoqLFVkIIITS7Bs2raFu3fKgjGn9aqcr7mNMrKqXD9peLuXZlmQ8Qj85ZN4BINMwru 6JlV9e1CoqlCucXlPyXKoauMnOFFVUmvSJASAMFX3pL7qOV4MILSj+f3P7fmrlgjwHmj 8IiXNb5ytN8HCR8hJBcH/NfG1uPUdQAXprkDqKkKNJsGy1vFON9T6DAqNAE3CX8SnkXP RCpAfnkNMSoioVETtGCtlXksIqw2IBIJb6GPiG97wgPOa4XhTP6X2FH1hWW2upASggN3 kCfv+J6lsa6zV/5q0yaa5pxXyaXeNJ/ahmLPT0ZB+Yhsovk5NKaXoOQyfSfYdrxIUqQr 1E9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740381414; x=1740986214; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eS5eqM+Cjh8hMR+i/eN58WnJ3+4iziz4nMKxMrjajbM=; b=nYS3NYubfgSGU0C/lU+fJeL84VbcefTRaU/sxV2F0VNPsx9OA0BPKujdbAJRXZkqB4 gE7jLf7VbR4jcsi76zA/wunYuNCet9TcT0hksO1IZH1Uq9vtQntPxexLflMEuF0Hxo6d w/c3uyRp7OiMhFTXTwXrfzcjQJwT4YRdPxbi72dDpYHl9DvyL/0C5uShB3IqkJNkHZ2f 2/XBlTa5ulyqIW1vUqtG/wx1WqUP+EaiYWPpPn0ZpkSf7PfRNod0QplvlVkx7cjNaFhB uQBxId5Qpr4e/qoKxbcrc18wCTrs1O2o5g7jDRcrl1X386muSjEjgvAyDYPUcE8oa59+ dyvA== X-Gm-Message-State: AOJu0YxoyC4pNNxihYjuVPpuv3lQqRMf0NMTIxmbZxFlGY8Ul1PfrrqU 192vnz2x43ESsPo9inTbuDt7ImwG3ES3t/PTZonm73MZnX3zdlKdteahiiJS X-Gm-Gg: ASbGncsSB2OpuzesaIXDo1sb8R4KSCb1wW0jHdjXy5gw4rUmwtPNGsTjKB1+x0c/kOn KbrgPDYdd30KblZhY+iA1re7jWO/Fe7GthwbeR1ycGYJNnTNKF9goZ7vQEWT5ifWvNsFdLxojTO Pq+CzE/uthkiA8mz4enKiTCn9nxu3jD4uj9kwpQq/WxWoZdID8OkTqd5NNTmt+DOlZ2tVBE5jHS 29ueaKlkn+5xVCt53FNUdzpfVSQkeGfPDDRRJme0el7gid25TNNur4Mu5a2jWE90kyhm3fWpKly PzYioII8c1HlT2s9OzI4Z7584/eC7zKVbpwbcZ7VEC7vWz9MhvkjclK9FGo= X-Google-Smtp-Source: AGHT+IG5G1mmsqSyhuvjiWYl3mB/fsyiVNwV8URTc+tj5W6kqacC9ZCjbLzN4VRK0S7L37BnZrIzBA== X-Received: by 2002:a05:6a21:99aa:b0:1e0:dcc5:164d with SMTP id adf61e73a8af0-1eef3c49154mr25738752637.8.1740381414304; Sun, 23 Feb 2025 23:16:54 -0800 (PST) Received: from YAMARURI (pl52086.ag1212.nttpc.ne.jp. [1.33.247.118]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-732581df0bbsm17564471b3a.156.2025.02.23.23.16.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Feb 2025 23:16:53 -0800 (PST) From: AKIYAMA Kouhei Date: Mon, 24 Feb 2025 16:16:45 +0900 Message-ID: <86bjur6cde.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Received-SPF: pass client-ip=2607:f8b0:4864:20::62a; envelope-from=misohena@gmail.com; helo=mail-pl1-x62a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Mailman-Approved-At: Mon, 24 Feb 2025 02:49:09 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dear Emacs Developers, Thank you for developing and maintaining Emacs. I have encountered some unexpected behavior in the `window-text-pixel-size` function and would like to share my findings in case they are helpful. I tested this on Emacs 30.1 for MS-Windows, launched with the following commands: wget https://ftp.gnu.org/gnu/emacs/windows/emacs-30/emacs-30.1.zip unzip emacs-30.1.zip cd bin ./emacs -Q * 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)) ;; -------------------------------------------------------- * 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: ;; -------------------------------------------------------- ;; 1. Evaluate the following code in the scratch buffer: ;; Note: あ = \u3042 (HIRAGANA LETTER A) (require 'cl-lib) (with-temp-buffer (insert "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n") (save-window-excursion (set-window-buffer nil (current-buffer)) (goto-char (point-min)) (cl-loop until (eobp) if (eolp) concat "\n" else concat (format " %s" (car (window-text-pixel-size nil (point) (1+ (point))))) do (forward-char)))) ;; Result " 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 -32 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 -50 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 -80 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 -98 8 8 8 8 8 8 8 8 8 8 8 " ;; A strange width is returned from the line after a full-width ;; character appears. ;; Expected " 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 " ;; -------------------------------------------------------- * Workaround Both issues occur when measuring the size of a partial text segment within a buffer. However, I found that narrowing the buffer to the target range before measuring avoids the problem: ;; -------------------------------------------------------- (with-temp-buffer (insert "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n") (save-window-excursion (set-window-buffer nil (current-buffer)) (goto-char (point-min)) (cl-loop until (eobp) if (eolp) concat "\n" else concat (format " %s" ;; [Workaround] (save-restriction (narrow-to-region (point) (1+ (point))) (car (window-text-pixel-size nil (point) (1+ (point)))))) do (forward-char)))) ;; -------------------------------------------------------- * Additional Context I am developing a package that displays file details on the right side of file names in Dired. This package needs to determine the width of icons (inserted by `all-the-icons-dired` or `nerd-icons-dired`) and thumbnails (inserted by `image-dired`). I use `window-text-pixel-size` for this purpose. Relevant code: https://github.com/misohena/dired-details-r/blob/5510aae2fb0b2fb1c55ef2c471c84ccd65359f35/dired-details-r.el#L379 Since I have already implemented a workaround using narrowing, this issue does not block my development. However, I wanted to report it in case it is useful. Best regards, -- # This email was machine-translated from Japanese. AKIYAMA Kouhei -- In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-24 built on AVALON Windowing system distributor 'Microsoft Corp.', version 10.0.26100 System Description: Microsoft Windows 10 Enterprise (v10.0.2009.26100.3194) Configured using: 'configure --with-modules --without-dbus --with-native-compilation=aot --without-compress-install --with-tree-sitter CFLAGS=-O2 prefix=/g/rel/install/emacs-30.1' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ja_JP.CP932 locale-coding-system: cp932 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr cl-extra help-mode warnings icons compile comint ansi-osc ansi-color ring comp-run bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils japan-util rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 81254 32625) (symbols 48 10237 0) (strings 32 21939 6240) (string-bytes 1 585829) (vectors 16 13241) (vector-slots 8 312318 15570) (floats 8 26 37) (intervals 56 3640 2771) (buffers 992 13)) From unknown Mon Aug 11 12:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76519: 30.1; Unexpected Results from window-text-pixel-size Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Feb 2025 19:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: AKIYAMA Kouhei Cc: 76519@debbugs.gnu.org Received: via spool by 76519-submit@debbugs.gnu.org id=B76519.174042542323556 (code B ref 76519); Mon, 24 Feb 2025 19:31:01 +0000 Received: (at 76519) by debbugs.gnu.org; 24 Feb 2025 19:30:23 +0000 Received: from localhost ([127.0.0.1]:42728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tme9n-00067s-9R for submit@debbugs.gnu.org; Mon, 24 Feb 2025 14:30:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34152) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tme9l-00067e-F6 for 76519@debbugs.gnu.org; Mon, 24 Feb 2025 14:30:21 -0500 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 1tme9d-0001oN-Cc; Mon, 24 Feb 2025 14:30:14 -0500 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=KdlOnB8gOOSVtes6VQIg5aC6ndvyTCD6WvkZQvRAA20=; b=F2xTavYKRF3q s8US9YHszObjr3UGJSwqQOeoFmeX+x5aMrIJCbeRYNyCwkTzD4izLhZHBZ4c+ab+LUS/tmNMF1uCj DhiTnMh9BQCt+p8kNQaGAiZgibfoM76K8ZjrRnlXNF0qHT+lC8yjqiGMKbXS3GFmFoyo5QuwW7z8O tG51x5Hlxlt3BUx+Q2PT0jO868WDdUAE3E+1yksdew/7IHQI0GbEuxat4n3kfxLfzLaMkektjnzGB O/FUO0yM4G+j6kJ9eRIZgzHVHas3i/fKFFWBpNOFgRU1pe8cy917nEu+WXxt+wk3bO/A5RTjS4XR4 CP03MncK+N2XDsbHCCXpGw==; Date: Mon, 24 Feb 2025 21:29:47 +0200 Message-Id: <86msebxhsk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86bjur6cde.fsf@gmail.com> (message from AKIYAMA Kouhei on Mon, 24 Feb 2025 16:16:45 +0900) References: <86bjur6cde.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: AKIYAMA Kouhei > 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. From unknown Mon Aug 11 12:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76519: 30.1; Unexpected Results from window-text-pixel-size Resent-From: AKIYAMA Kouhei Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Feb 2025 13:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 76519@debbugs.gnu.org Received: via spool by 76519-submit@debbugs.gnu.org id=B76519.174048909111752 (code B ref 76519); Tue, 25 Feb 2025 13:12:01 +0000 Received: (at 76519) by debbugs.gnu.org; 25 Feb 2025 13:11:31 +0000 Received: from localhost ([127.0.0.1]:45272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmuih-00033S-4P for submit@debbugs.gnu.org; Tue, 25 Feb 2025 08:11:31 -0500 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:52353) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tmt33-000399-IT for 76519@debbugs.gnu.org; Tue, 25 Feb 2025 06:24:26 -0500 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-543d8badc30so6353419e87.0 for <76519@debbugs.gnu.org>; Tue, 25 Feb 2025 03:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740482659; x=1741087459; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HSYkgMIje4zl0TluepkRyaxZGaN1OxVZ2kmYp5YmFUk=; b=Pz685ifFkPg8Mq7+v7RFQFuZRUAfYgmdi0BLR76iuANM2jTTAL2adSX+dmPDvD5wIC zq3MuwXRUwz5Kk5SaPw+Ig9/2JtRn4OARn42l/XQjY1AtgR3G9KpsM5UVGjkqlNSEY6w MPj8gyebww57qvxcf+PVlGOJZXQ7h2G57NjesFEeZLt5qwtorl7JAOHT0Ax2AOIncjPi x8EJrQ/Fk46XR8lR5Mxgzj3zEUdoYNxg202i4KXJKY1eWqe7jWJqPZjV8f07AGbUqLHX BiDOHWiz+md/xPqzHiZAh+BCp6gS0f6vtrco0GxKzU6FQXWN7ZO3x6aj6tQhaF3KhNjV ho1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740482659; x=1741087459; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HSYkgMIje4zl0TluepkRyaxZGaN1OxVZ2kmYp5YmFUk=; b=fAhIJ1S1mKpTwPAKqYNyZ7P3ZaVZdsLU4ILY4o2YsUKe76ecrcDS0vUfWENmt7pItb vWDI+wAffhNEYiiW4P8CKtKTZ6VLr3d6WIvh22ilab9IhjUmOGyCilBa8anuhn+J9l07 GphCMFRREqERvTy0zlj5+JYYtdpVHwGjQakHiZUbgDU+wpoAQWovoHnFzX4P8E5Dn4+2 4XVgj4ZkpLrrIPp8xtlHERzhMSlMg+N+Ex38V80goXHRcdx8lHginuAn7gzcFWa+DMsF ZQvN7JT8ZkTv/d6TCo/+JA++W40R71AAins1E/maf04Hq1fZJiFjxSmBoMWGfiw6V122 95oQ== X-Gm-Message-State: AOJu0YzxPVVUCvaEUlKfP6cY1wHsiUAYAJPiRoKT1nrkitcnc6r7Uc14 0uY79ACquzGlAGTYPRVCDbdffYcXe9pV5jPf43CtyQqC3UZKCQ+8Zf6UX451q72PcLKHeVXGXDE 1o4A3BWFkgTsOC23me1m0x7+Y7Pg= X-Gm-Gg: ASbGncvd9aY9dsZD+sadhm8K6B6EyGSQ/Wtd1FX+fI8DNLE9+6sw+4MDbtcd8vS6X2q 787QXlJSM4WiCOxR0pVHRv3Yi2GMs1jUZgpVC7DOWVicGaolcTG/SvQdrfiV/gXjfSx0WnCQ+1g aFeZ0pWw== X-Google-Smtp-Source: AGHT+IFn3GcehN95cvsy2XsZocVAL0mSl0wXrkDYDBdLKryAT4fb1N83zHjuWB0roSvFeAV8IQngrayA9mkTnYPj97U= X-Received: by 2002:a05:6512:224a:b0:545:2d94:82a with SMTP id 2adb3069b0e04-548510eb0damr1098864e87.32.1740482658604; Tue, 25 Feb 2025 03:24:18 -0800 (PST) MIME-Version: 1.0 References: <86bjur6cde.fsf@gmail.com> <86msebxhsk.fsf@gnu.org> In-Reply-To: <86msebxhsk.fsf@gnu.org> From: AKIYAMA Kouhei Date: Tue, 25 Feb 2025 20:24:07 +0900 X-Gm-Features: AWEUYZkiQwxGcttaIjHRC4sWvHT29gbnP_fZlnzwEzr7u2fzyIJnUw8kADSOyQ8 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Mailman-Approved-At: Tue, 25 Feb 2025 08:11:29 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From unknown Mon Aug 11 12:54:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76519: 30.1; Unexpected Results from window-text-pixel-size Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Feb 2025 12:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: AKIYAMA Kouhei Cc: 76519@debbugs.gnu.org Received: via spool by 76519-submit@debbugs.gnu.org id=B76519.174057453330535 (code B ref 76519); Wed, 26 Feb 2025 12:56:02 +0000 Received: (at 76519) by debbugs.gnu.org; 26 Feb 2025 12:55:33 +0000 Received: from localhost ([127.0.0.1]:51420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnGwm-0007wP-OP for submit@debbugs.gnu.org; Wed, 26 Feb 2025 07:55:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48578) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnGwj-0007wB-Tw for 76519@debbugs.gnu.org; Wed, 26 Feb 2025 07:55:30 -0500 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 1tnGwe-0005OL-7X; Wed, 26 Feb 2025 07:55:24 -0500 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=kA2/NII2Sl8sJesXn28qGVCHnf2pDA8/G3keDsVTrIo=; b=atd/lTxpaTz4 +QojfYkL6EBW9FwvhTBwqrZ687jud5Y6MQO0lbrcqkM5deAm8lHMXwb7iVEj7w1ykB3evEsTwLMW4 MY/VrXgpgSsoEBJwp6iUvqmkpkuIH3AovWRhHjrBAbDsJo+3pwTxxc8QUVUDhBWSguUfv2Ksaq170 4Euu+w0E3NFZNuFgy4llMM3rKYieysE9pd8SOwdy6VajUk3eKwkMEuWoCkPoNvkumOYraCMca+mhL fhmnM4npgdghW/QlN+tr9VWvvIsoU4XliUx31pkeicz/dc/KsJtR8+mgxP7aLNlg4AAwAYwnyp4pj QXoIGxKhBTkynPZtKfHikg==; Date: Wed, 26 Feb 2025 14:55:18 +0200 Message-Id: <86bjuox3ux.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from AKIYAMA Kouhei on Tue, 25 Feb 2025 20:24:07 +0900) References: <86bjur6cde.fsf@gmail.com> <86msebxhsk.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: AKIYAMA Kouhei > Date: Tue, 25 Feb 2025 20:24:07 +0900 > Cc: 76519@debbugs.gnu.org > > > 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). Yes, overlays cannot be part of a string, so string-pixel-width will not do the job when the buffer text has overlay strings. > 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 Thanks, fixed. > > > * 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! You're welcome. From unknown Mon Aug 11 12:54:18 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: AKIYAMA Kouhei Subject: bug#76519: closed (Re: bug#76519: 30.1; Unexpected Results from window-text-pixel-size) Message-ID: References: <86ldteh7ju.fsf@gnu.org> <86bjur6cde.fsf@gmail.com> X-Gnu-PR-Message: they-closed 76519 X-Gnu-PR-Package: emacs Reply-To: 76519@debbugs.gnu.org Date: Sun, 09 Mar 2025 09:35:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1741512902-18179-1" This is a multi-part message in MIME format... ------------=_1741512902-18179-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #76519: 30.1; Unexpected Results from window-text-pixel-size which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 76519@debbugs.gnu.org. --=20 76519: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D76519 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1741512902-18179-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 76519-done) by debbugs.gnu.org; 9 Mar 2025 09:34:23 +0000 Received: from localhost ([127.0.0.1]:58308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1trD39-0004iB-Ay for submit@debbugs.gnu.org; Sun, 09 Mar 2025 05:34:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52806) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1trD2q-0004hB-U5 for 76519-done@debbugs.gnu.org; Sun, 09 Mar 2025 05:34:05 -0400 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 1trD2l-0002fW-LR; Sun, 09 Mar 2025 05:33:59 -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=adsBg5clCTMy8gW/5MFCrLc9e5fzUX4VgMVh2Ard/xY=; b=RkmhzuK2Q4Yz +9TCjwg9XD6xVZO4awgYUT4OxZWE1E5K1XJZloi5OSs+ujOYflJ4AwAJj9Y5VjQyv1ZQ8ZwI+koKm LObZQjh9yMu3H7yUpvy+ZBzB8SnPxB25oiSgN/C2kZBMdvNTyg4Zf5TB41UeNQrNwbPRPI4BP1Fez HApJybxyL5QRJTKUbhyTEq76azXYq5JfNDzIe0kAsmwM2p3cUNwYrJ8BXa8yWp3XyphLfdbgC9SI2 KFno4F7E+0kz1inbg+aKAWTwWWy5DY3nGXk3sXp4jpol/u2FnTcAYRTBVwkXb8PTgBEWd9tpiOhnO upUDT6FVxW+UnsCnvRPrBA==; Date: Sun, 09 Mar 2025 11:33:57 +0200 Message-Id: <86ldteh7ju.fsf@gnu.org> From: Eli Zaretskii To: misohena@gmail.com In-Reply-To: <86bjuox3ux.fsf@gnu.org> (message from Eli Zaretskii on Wed, 26 Feb 2025 14:55:18 +0200) Subject: Re: bug#76519: 30.1; Unexpected Results from window-text-pixel-size References: <86bjur6cde.fsf@gmail.com> <86msebxhsk.fsf@gnu.org> <86bjuox3ux.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76519-done Cc: 76519-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 76519@debbugs.gnu.org > Date: Wed, 26 Feb 2025 14:55:18 +0200 > From: Eli Zaretskii > > > From: AKIYAMA Kouhei > > Date: Tue, 25 Feb 2025 20:24:07 +0900 > > Cc: 76519@debbugs.gnu.org > > > > > 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). > > Yes, overlays cannot be part of a string, so string-pixel-width will > not do the job when the buffer text has overlay strings. > > > 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 > > Thanks, fixed. > > > > > * 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! > > You're welcome. No further comments, so I'm closing this bug now. ------------=_1741512902-18179-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 24 Feb 2025 07:49:11 +0000 Received: from localhost ([127.0.0.1]:38273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmTDC-0006Vf-AW for submit@debbugs.gnu.org; Mon, 24 Feb 2025 02:49:11 -0500 Received: from lists.gnu.org ([2001:470:142::17]:36826) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmSiB-00052h-Oc for submit@debbugs.gnu.org; Mon, 24 Feb 2025 02:17:08 -0500 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 1tmSi4-00048i-MZ for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2025 02:17:00 -0500 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tmSi2-00023k-Jl for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2025 02:17:00 -0500 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-22128b7d587so75204905ad.3 for ; Sun, 23 Feb 2025 23:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740381414; x=1740986214; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=eS5eqM+Cjh8hMR+i/eN58WnJ3+4iziz4nMKxMrjajbM=; b=RoqLFVkIIITS7Bs2raFu3fKgjGn9aqcr7mNMrKqXD9peLuXZlmQ8Qj85ZN4BINMwru 6JlV9e1CoqlCucXlPyXKoauMnOFFVUmvSJASAMFX3pL7qOV4MILSj+f3P7fmrlgjwHmj 8IiXNb5ytN8HCR8hJBcH/NfG1uPUdQAXprkDqKkKNJsGy1vFON9T6DAqNAE3CX8SnkXP RCpAfnkNMSoioVETtGCtlXksIqw2IBIJb6GPiG97wgPOa4XhTP6X2FH1hWW2upASggN3 kCfv+J6lsa6zV/5q0yaa5pxXyaXeNJ/ahmLPT0ZB+Yhsovk5NKaXoOQyfSfYdrxIUqQr 1E9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740381414; x=1740986214; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eS5eqM+Cjh8hMR+i/eN58WnJ3+4iziz4nMKxMrjajbM=; b=nYS3NYubfgSGU0C/lU+fJeL84VbcefTRaU/sxV2F0VNPsx9OA0BPKujdbAJRXZkqB4 gE7jLf7VbR4jcsi76zA/wunYuNCet9TcT0hksO1IZH1Uq9vtQntPxexLflMEuF0Hxo6d w/c3uyRp7OiMhFTXTwXrfzcjQJwT4YRdPxbi72dDpYHl9DvyL/0C5uShB3IqkJNkHZ2f 2/XBlTa5ulyqIW1vUqtG/wx1WqUP+EaiYWPpPn0ZpkSf7PfRNod0QplvlVkx7cjNaFhB uQBxId5Qpr4e/qoKxbcrc18wCTrs1O2o5g7jDRcrl1X386muSjEjgvAyDYPUcE8oa59+ dyvA== X-Gm-Message-State: AOJu0YxoyC4pNNxihYjuVPpuv3lQqRMf0NMTIxmbZxFlGY8Ul1PfrrqU 192vnz2x43ESsPo9inTbuDt7ImwG3ES3t/PTZonm73MZnX3zdlKdteahiiJS X-Gm-Gg: ASbGncsSB2OpuzesaIXDo1sb8R4KSCb1wW0jHdjXy5gw4rUmwtPNGsTjKB1+x0c/kOn KbrgPDYdd30KblZhY+iA1re7jWO/Fe7GthwbeR1ycGYJNnTNKF9goZ7vQEWT5ifWvNsFdLxojTO Pq+CzE/uthkiA8mz4enKiTCn9nxu3jD4uj9kwpQq/WxWoZdID8OkTqd5NNTmt+DOlZ2tVBE5jHS 29ueaKlkn+5xVCt53FNUdzpfVSQkeGfPDDRRJme0el7gid25TNNur4Mu5a2jWE90kyhm3fWpKly PzYioII8c1HlT2s9OzI4Z7584/eC7zKVbpwbcZ7VEC7vWz9MhvkjclK9FGo= X-Google-Smtp-Source: AGHT+IG5G1mmsqSyhuvjiWYl3mB/fsyiVNwV8URTc+tj5W6kqacC9ZCjbLzN4VRK0S7L37BnZrIzBA== X-Received: by 2002:a05:6a21:99aa:b0:1e0:dcc5:164d with SMTP id adf61e73a8af0-1eef3c49154mr25738752637.8.1740381414304; Sun, 23 Feb 2025 23:16:54 -0800 (PST) Received: from YAMARURI (pl52086.ag1212.nttpc.ne.jp. [1.33.247.118]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-732581df0bbsm17564471b3a.156.2025.02.23.23.16.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Feb 2025 23:16:53 -0800 (PST) From: AKIYAMA Kouhei To: bug-gnu-emacs@gnu.org Subject: 30.1; Unexpected Results from window-text-pixel-size X-Debbugs-Cc: Date: Mon, 24 Feb 2025 16:16:45 +0900 Message-ID: <86bjur6cde.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Received-SPF: pass client-ip=2607:f8b0:4864:20::62a; envelope-from=misohena@gmail.com; helo=mail-pl1-x62a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 24 Feb 2025 02:49:09 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dear Emacs Developers, Thank you for developing and maintaining Emacs. I have encountered some unexpected behavior in the `window-text-pixel-size` function and would like to share my findings in case they are helpful. I tested this on Emacs 30.1 for MS-Windows, launched with the following commands: wget https://ftp.gnu.org/gnu/emacs/windows/emacs-30/emacs-30.1.zip unzip emacs-30.1.zip cd bin ./emacs -Q * 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)) ;; -------------------------------------------------------- * 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: ;; -------------------------------------------------------- ;; 1. Evaluate the following code in the scratch buffer: ;; Note: あ = \u3042 (HIRAGANA LETTER A) (require 'cl-lib) (with-temp-buffer (insert "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n") (save-window-excursion (set-window-buffer nil (current-buffer)) (goto-char (point-min)) (cl-loop until (eobp) if (eolp) concat "\n" else concat (format " %s" (car (window-text-pixel-size nil (point) (1+ (point))))) do (forward-char)))) ;; Result " 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 -32 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 -50 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 -80 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 -98 8 8 8 8 8 8 8 8 8 8 8 " ;; A strange width is returned from the line after a full-width ;; character appears. ;; Expected " 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 14 14 14 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 " ;; -------------------------------------------------------- * Workaround Both issues occur when measuring the size of a partial text segment within a buffer. However, I found that narrowing the buffer to the target range before measuring avoids the problem: ;; -------------------------------------------------------- (with-temp-buffer (insert "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n" "aaaaaaaaaaaaaaaaaaaaaaaa\n" "あああbbbbbbbbbbbbbbbbbbbb\n") (save-window-excursion (set-window-buffer nil (current-buffer)) (goto-char (point-min)) (cl-loop until (eobp) if (eolp) concat "\n" else concat (format " %s" ;; [Workaround] (save-restriction (narrow-to-region (point) (1+ (point))) (car (window-text-pixel-size nil (point) (1+ (point)))))) do (forward-char)))) ;; -------------------------------------------------------- * Additional Context I am developing a package that displays file details on the right side of file names in Dired. This package needs to determine the width of icons (inserted by `all-the-icons-dired` or `nerd-icons-dired`) and thumbnails (inserted by `image-dired`). I use `window-text-pixel-size` for this purpose. Relevant code: https://github.com/misohena/dired-details-r/blob/5510aae2fb0b2fb1c55ef2c471c84ccd65359f35/dired-details-r.el#L379 Since I have already implemented a workaround using narrowing, this issue does not block my development. However, I wanted to report it in case it is useful. Best regards, -- # This email was machine-translated from Japanese. AKIYAMA Kouhei -- In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-24 built on AVALON Windowing system distributor 'Microsoft Corp.', version 10.0.26100 System Description: Microsoft Windows 10 Enterprise (v10.0.2009.26100.3194) Configured using: 'configure --with-modules --without-dbus --with-native-compilation=aot --without-compress-install --with-tree-sitter CFLAGS=-O2 prefix=/g/rel/install/emacs-30.1' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ja_JP.CP932 locale-coding-system: cp932 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr cl-extra help-mode warnings icons compile comint ansi-osc ansi-color ring comp-run bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils japan-util rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 81254 32625) (symbols 48 10237 0) (strings 32 21939 6240) (string-bytes 1 585829) (vectors 16 13241) (vector-slots 8 312318 15570) (floats 8 26 37) (intervals 56 3640 2771) (buffers 992 13)) ------------=_1741512902-18179-1--