From unknown Sat Aug 09 01:08:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines Resent-From: David Ponce Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Sep 2024 22:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 73129 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73129@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.172583415130589 (code B ref -1); Sun, 08 Sep 2024 22:23:02 +0000 Received: (at submit) by debbugs.gnu.org; 8 Sep 2024 22:22:31 +0000 Received: from localhost ([127.0.0.1]:60258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snQIg-0007xI-W1 for submit@debbugs.gnu.org; Sun, 08 Sep 2024 18:22:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:54178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snQIe-0007x8-Oh for submit@debbugs.gnu.org; Sun, 08 Sep 2024 18:22:29 -0400 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 1snQIY-0005W1-GU for bug-gnu-emacs@gnu.org; Sun, 08 Sep 2024 18:22:24 -0400 Received: from smtp-26.smtpout.orange.fr ([80.12.242.26] helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1snQIV-0005hs-8G for bug-gnu-emacs@gnu.org; Sun, 08 Sep 2024 18:22:22 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id nQINsls3DQYYunQINsjKHw; Mon, 09 Sep 2024 00:22:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1725834133; bh=aTiBrMz/4VEju3pejI30rqdqFLvppE9BaHgA7BcVt1s=; h=Message-ID:Date:MIME-Version:To:From:Subject; b=QmucgkLvonCqqKx0fgJ7eTZwHwq8xza/o+8WS7WH/mqnO/H3bnVabUGZ086OKwcaq dzL3yrC4Z07PvJejRHBE6Ap/dvo7p4mEN0po3oS1C4gD+AMcuXoPuCR8plWBxMjoqv NCdD9UMX+NVkQteHXTRFT9WRakbn3z3aJjAJ4f5tUqn0Y2BGpBbU0ZGzbZzj9PfGAV XSGfBe2GiAR5Iab1aiBP52qkHr4eM8UFGLzyeOl1PGayNsJAbuZo0dANOnR0l0BaDq c84oCduQ4JPkxd19IJk28N4vP1aZFa7tn1nrV9v8+S4YqGBU6bgPnG+QMzptv60TQQ Tswy/223iOHEA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 09 Sep 2024 00:22:13 +0200 X-ME-IP: 2.7.225.247 Message-ID: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> Date: Mon, 9 Sep 2024 00:22:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr, en-US From: David Ponce Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=80.12.242.26; envelope-from=da_vid@orange.fr; helo=smtp.smtpout.orange.fr 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.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: -2.3 (--) Hello, Its seems that the function `buffer-text-pixel-size' is not working as described when there are newlines in the buffer. Here is a quick illustration (on my laptop (frame-char-width) returns 12 pixels): ;; As expected. (with-temp-buffer (insert "abcdef") (car (buffer-text-pixel-size nil nil t))) 72 ;; I suppose it is as expected because newline is not displayed. (with-temp-buffer (insert "\n") (car (buffer-text-pixel-size nil nil t))) 0 ;; ? (with-temp-buffer (insert "abcd\nef") (car (buffer-text-pixel-size nil nil t))) 48 The doc string of `buffer-text-pixel-size' mentions: "Return size of whole text of BUFFER-OR-NAME in WINDOW." So ,I expect that the last example will return 72px (6 x 12px) + 0px for the newline. But the result is 48px, which means that all the text after the first newline is not counted. This also impacts "string-pixel-width" which is supposed to return the pixel size of the passed string, not part of it: (string-pixel-width "abcdef") => 72 (string-pixel-width "\n") => 0 (string-pixel-width "abcd\nef") => 48 (string-pixel-width "abcd\nef\ngh") => 48 At least this limitation should be mentioned in the doc string? A possible fix for `string-pixel-width' could be to remove all the newlines from the passed string before to call `buffer-text-pixel-size'? Something like this: diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 4cdb065feeb..c68b3b37f9b 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -406,6 +406,11 @@ string-pixel-width face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) (insert string) + ;; Remove newlines. + (forward-line 0) + (while (not (bobp)) + (delete-char -1) + (forward-line 0)) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. (remove-text-properties Thanks! In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) Repository revision: 2ce0d397b12cafcb3e1ac5630bc3fbca61bd6b87 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 40 (KDE Plasma) Configured using: 'configure --with-x-toolkit=gtk3 --with-cairo-xcb --with-native-compilation=no PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_TIME: fr_FR.utf8 value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix From unknown Sat Aug 09 01:08:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Sep 2024 11:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73129 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Ponce Cc: 73129@debbugs.gnu.org Received: via spool by 73129-submit@debbugs.gnu.org id=B73129.172588169430609 (code B ref 73129); Mon, 09 Sep 2024 11:35:02 +0000 Received: (at 73129) by debbugs.gnu.org; 9 Sep 2024 11:34:54 +0000 Received: from localhost ([127.0.0.1]:60799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sncfW-0007xc-DV for submit@debbugs.gnu.org; Mon, 09 Sep 2024 07:34:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sncfU-0007xJ-Ln for 73129@debbugs.gnu.org; Mon, 09 Sep 2024 07:34:53 -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 1sncfL-0000p3-4L; Mon, 09 Sep 2024 07:34:43 -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=7Uu8oiTo2/AJSvHTX76jY/IyxJy2DhIaagACPV8Aahs=; b=e8199RfdTpC8 BeG7SOE/GyEM+fONPpkGxTTiP+3bQGRbCW0DjLiKUMvXd7qIGotjZsqHti/bf5I8V0K0/RQbitWNT ZuLlJwHJ9/uGQoiN5K1rVQdhny/vv9oAbdH6WQMfmOdQsWG5lgAwnvMqEH0kGP/hi3f+XWVusvZLm aXjXFX9pAM3s6WTnblZB7+WoeSzExW8JBn3ujrFRjso+mmHpyMpGMqqTFM/x9n4vKVRDIbv6yD8C8 4XMVfmCTII/SakJm2ZP/nnOGvjdT6PqBTRbWwaectj9fjnxBzqrgKjjO28zKLJuCTQQEz+ZTdMhJ7 EN28B1kh6XWXotQTP7RHgg==; Date: Mon, 09 Sep 2024 14:34:38 +0300 Message-Id: <868qw1vz5d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> (bug-gnu-emacs@gnu.org) References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> 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 (---) > Date: Mon, 9 Sep 2024 00:22:11 +0200 > From: David Ponce via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Its seems that the function `buffer-text-pixel-size' is not working > as described when there are newlines in the buffer. Here is a quick > illustration (on my laptop (frame-char-width) returns 12 pixels): > > ;; As expected. > (with-temp-buffer > (insert "abcdef") > (car (buffer-text-pixel-size nil nil t))) > 72 > > ;; I suppose it is as expected because newline is not displayed. > (with-temp-buffer > (insert "\n") > (car (buffer-text-pixel-size nil nil t))) > 0 > > ;; ? > (with-temp-buffer > (insert "abcd\nef") > (car (buffer-text-pixel-size nil nil t))) > 48 The above is the intended behavior, assuming that the default width of the frame's characters is 12 in your case. The maximum width of the text "abcd\nef" is 4 characters ("abcd"), which are 12*4 = 48 pixels. The part after the newline is only 2 characters, so it is narrower, and does not affect the result. IOW, buffer-text-pixel-size measures the 2D _dimensions_ of the text, not is total width. > The doc string of `buffer-text-pixel-size' mentions: > > "Return size of whole text of BUFFER-OR-NAME in WINDOW." It also says: The return value is a cons of the maximum pixel-width of any text line and the pixel-height of all the text lines of the buffer specified by BUFFER-OR-NAME. Does the above explain the behavior you see? This is not a bug. > So ,I expect that the last example will return 72px (6 x 12px) + 0px > for the newline. But the result is 48px, which means that all the > text after the first newline is not counted. Your expectations are incorrect, see above. > This also impacts "string-pixel-width" which is supposed to return > the pixel size of the passed string, not part of it: > > (string-pixel-width "abcdef") => 72 > (string-pixel-width "\n") => 0 > (string-pixel-width "abcd\nef") => 48 > (string-pixel-width "abcd\nef\ngh") => 48 Yes. If you want the _total_ width of a string, remove the newlines from it. I think I understand the source of your confusion, so I have now clarified these subtle points in the doc strings of window-text-pixel-size, buffer-text-pixel-size, and string-pixel-width. > At least this limitation should be mentioned in the doc string? I've now done so (and they are not limitations, but conscious design decisions which have good reasons). > A possible fix for `string-pixel-width' could be to remove all > the newlines from the passed string before to call > `buffer-text-pixel-size'? Something like this: Thanks, but that would be the wrong thing. If the caller wants a total width, the caller should remover the newlines or measure each substring separately and add the results. May I ask where and for what purpose did you need to measure pixel width of a string that included newlines? From unknown Sat Aug 09 01:08:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines Resent-From: David Ponce Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Sep 2024 12:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73129 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73129@debbugs.gnu.org Received: via spool by 73129-submit@debbugs.gnu.org id=B73129.172588659414936 (code B ref 73129); Mon, 09 Sep 2024 12:57:01 +0000 Received: (at 73129) by debbugs.gnu.org; 9 Sep 2024 12:56:34 +0000 Received: from localhost ([127.0.0.1]:60844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sndwX-0003sp-4s for submit@debbugs.gnu.org; Mon, 09 Sep 2024 08:56:33 -0400 Received: from smtp-73.smtpout.orange.fr ([80.12.242.73]:63387 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sndwU-0003sg-IM for 73129@debbugs.gnu.org; Mon, 09 Sep 2024 08:56:31 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id ndwMsFlX3lL4CndwMsRuVc; Mon, 09 Sep 2024 14:56:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1725886585; bh=gbuRedXSOstkWt6HYSP7HCCkK8tGM4TgdTbOvias5Wo=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=GpysuSSCa7A/y7UZ4TFbHPIa90clHXDUXAC0zZmvM1TGIdJLcar4yh9Zbt54QcMba xav6bKDs9hXGNo2v3CaPvZi8PS9/Sv8Gs0hi9WJpnJaAiQjI7NZCzLJMv/+s9ibgnB n6BsOrHu2TB/1iB5ddlpzH+QhkGvYGX+IADcLcRTapZIFMtS2uheqrG0TiS0h6CiDw 7s0YRvfp4MqrCUIrdhlCzpYGJGxkWkQj5HC/ke5WCp/6gutxSMFudbL51AU7ilQTX5 SpaVMYkdak3WxwYaz3HPUs0J0tucTK+wgNJ8SHYNqMn4fxMKev5+d8oU7DKoULHR9G zoqA6k52McV7g== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 09 Sep 2024 14:56:25 +0200 X-ME-IP: 2.7.225.247 Message-ID: <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> Date: Mon, 9 Sep 2024 14:56:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> <868qw1vz5d.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <868qw1vz5d.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) 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 (-) On 09/09/2024 1:34 PM, Eli Zaretskii wrote: >> Date: Mon, 9 Sep 2024 00:22:11 +0200 >> From: David Ponce via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Its seems that the function `buffer-text-pixel-size' is not working >> as described when there are newlines in the buffer. Here is a quick >> illustration (on my laptop (frame-char-width) returns 12 pixels): >> >> ;; As expected. >> (with-temp-buffer >> (insert "abcdef") >> (car (buffer-text-pixel-size nil nil t))) >> 72 >> >> ;; I suppose it is as expected because newline is not displayed. >> (with-temp-buffer >> (insert "\n") >> (car (buffer-text-pixel-size nil nil t))) >> 0 >> >> ;; ? >> (with-temp-buffer >> (insert "abcd\nef") >> (car (buffer-text-pixel-size nil nil t))) >> 48 > > The above is the intended behavior, assuming that the default width of > the frame's characters is 12 in your case. The maximum width of the > text "abcd\nef" is 4 characters ("abcd"), which are 12*4 = 48 pixels. > The part after the newline is only 2 characters, so it is narrower, > and does not affect the result. > > IOW, buffer-text-pixel-size measures the 2D _dimensions_ of the text, > not is total width. Thanks for clarifying. > >> The doc string of `buffer-text-pixel-size' mentions: >> >> "Return size of whole text of BUFFER-OR-NAME in WINDOW." > > It also says: > > The return value is a cons of the maximum pixel-width of any text > line and the pixel-height of all the text lines of the buffer > specified by BUFFER-OR-NAME. > > Does the above explain the behavior you see? Yes > > This is not a bug. > >> So ,I expect that the last example will return 72px (6 x 12px) + 0px >> for the newline. But the result is 48px, which means that all the >> text after the first newline is not counted. > > Your expectations are incorrect, see above. > >> This also impacts "string-pixel-width" which is supposed to return >> the pixel size of the passed string, not part of it: >> >> (string-pixel-width "abcdef") => 72 >> (string-pixel-width "\n") => 0 >> (string-pixel-width "abcd\nef") => 48 >> (string-pixel-width "abcd\nef\ngh") => 48 > > Yes. If you want the _total_ width of a string, remove the newlines > from it. > > I think I understand the source of your confusion, so I have now > clarified these subtle points in the doc strings of > window-text-pixel-size, buffer-text-pixel-size, and > string-pixel-width. Thanks you very much! > >> At least this limitation should be mentioned in the doc string? > > I've now done so (and they are not limitations, but conscious design > decisions which have good reasons). > >> A possible fix for `string-pixel-width' could be to remove all >> the newlines from the passed string before to call >> `buffer-text-pixel-size'? Something like this: > > Thanks, but that would be the wrong thing. If the caller wants a > total width, the caller should remover the newlines or measure each > substring separately and add the results. I agree now that you clarified the behavior of `string-pixel-width' when it is passed a string with embedded newlines. > May I ask where and for what purpose did you need to measure pixel > width of a string that included newlines? Actually, the current behavior doesn't really impact my current work. I just noticed it while experimenting, having passed to `string-pixel-width' a buffer substring that spanned multiple lines. And I thought it would be good to, at least, clarify the behavior I observed ;-) You can close this bug. Many thanks again for your time and assistance! From unknown Sat Aug 09 01:08:53 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: David Ponce Subject: bug#73129: closed (Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines) Message-ID: References: <86wmjlufgs.fsf@gnu.org> <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> X-Gnu-PR-Message: they-closed 73129 X-Gnu-PR-Package: emacs Reply-To: 73129@debbugs.gnu.org Date: Mon, 09 Sep 2024 13:26:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1725888362-21916-1" This is a multi-part message in MIME format... ------------=_1725888362-21916-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #73129: 31.0.50; buffer-text-pixel-size vs. newlines 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 73129@debbugs.gnu.org. --=20 73129: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73129 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1725888362-21916-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 73129-done) by debbugs.gnu.org; 9 Sep 2024 13:25:21 +0000 Received: from localhost ([127.0.0.1]:60915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sneOP-0005gK-Bh for submit@debbugs.gnu.org; Mon, 09 Sep 2024 09:25:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sneOM-0005YF-VG for 73129-done@debbugs.gnu.org; Mon, 09 Sep 2024 09:25:19 -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 1sneOD-0006Lk-Sl; Mon, 09 Sep 2024 09:25:09 -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=pPrZfRaWRD42r2mS28Us6x2WRCTxeF7URaWwDgyzI/g=; b=L7NN7RPmCV3W Osnc4hye+Ut7CkPuZhCHDJNvbC2TjWm4nO6+/KINzaLOWCRF3LEb7jxSgF0xDAadwEoBIeIwX24jG /5zwQjxN4ayN4cHqYRAEBluFRt3bd0zfRXF4RLD0wNMZ7JWuo2TEuqLZOguUrRhgfDi0fC+iXC4ZK 18I2Te8pwVeIclK0POarGKPGNFqUgrd7sYPB/Dfw4MlF46UXYa54swbnqpflbxCTAo+OpYOaQkFmI egykhNIipy7lH/KCSm6FC+xdmYqtu4NwgO3cdFReDfHZ7R5CdbuRyXLh3Qxi/MTVNsf0K8yECYfv6 wsjbSuMnEK4IXiwnVqgVxw==; Date: Mon, 09 Sep 2024 16:25:07 +0300 Message-Id: <86wmjlufgs.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> (message from David Ponce on Mon, 9 Sep 2024 14:56:22 +0200) Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> <868qw1vz5d.fsf@gnu.org> <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73129-done Cc: 73129-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 (---) > Date: Mon, 9 Sep 2024 14:56:22 +0200 > Cc: 73129@debbugs.gnu.org > From: David Ponce > > > May I ask where and for what purpose did you need to measure pixel > > width of a string that included newlines? > > Actually, the current behavior doesn't really impact my current work. I > just noticed it while experimenting, having passed to `string-pixel-width' > a buffer substring that spanned multiple lines. And I thought it would be > good to, at least, clarify the behavior I observed ;-) > > You can close this bug. Thanks, closing. ------------=_1725888362-21916-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 8 Sep 2024 22:22:31 +0000 Received: from localhost ([127.0.0.1]:60258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snQIg-0007xI-W1 for submit@debbugs.gnu.org; Sun, 08 Sep 2024 18:22:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:54178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snQIe-0007x8-Oh for submit@debbugs.gnu.org; Sun, 08 Sep 2024 18:22:29 -0400 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 1snQIY-0005W1-GU for bug-gnu-emacs@gnu.org; Sun, 08 Sep 2024 18:22:24 -0400 Received: from smtp-26.smtpout.orange.fr ([80.12.242.26] helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1snQIV-0005hs-8G for bug-gnu-emacs@gnu.org; Sun, 08 Sep 2024 18:22:22 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id nQINsls3DQYYunQINsjKHw; Mon, 09 Sep 2024 00:22:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1725834133; bh=aTiBrMz/4VEju3pejI30rqdqFLvppE9BaHgA7BcVt1s=; h=Message-ID:Date:MIME-Version:To:From:Subject; b=QmucgkLvonCqqKx0fgJ7eTZwHwq8xza/o+8WS7WH/mqnO/H3bnVabUGZ086OKwcaq dzL3yrC4Z07PvJejRHBE6Ap/dvo7p4mEN0po3oS1C4gD+AMcuXoPuCR8plWBxMjoqv NCdD9UMX+NVkQteHXTRFT9WRakbn3z3aJjAJ4f5tUqn0Y2BGpBbU0ZGzbZzj9PfGAV XSGfBe2GiAR5Iab1aiBP52qkHr4eM8UFGLzyeOl1PGayNsJAbuZo0dANOnR0l0BaDq c84oCduQ4JPkxd19IJk28N4vP1aZFa7tn1nrV9v8+S4YqGBU6bgPnG+QMzptv60TQQ Tswy/223iOHEA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 09 Sep 2024 00:22:13 +0200 X-ME-IP: 2.7.225.247 Message-ID: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> Date: Mon, 9 Sep 2024 00:22:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr, en-US To: bug-gnu-emacs@gnu.org From: David Ponce Subject: 31.0.50; buffer-text-pixel-size vs. newlines Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=80.12.242.26; envelope-from=da_vid@orange.fr; helo=smtp.smtpout.orange.fr 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit 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: -2.3 (--) Hello, Its seems that the function `buffer-text-pixel-size' is not working as described when there are newlines in the buffer. Here is a quick illustration (on my laptop (frame-char-width) returns 12 pixels): ;; As expected. (with-temp-buffer (insert "abcdef") (car (buffer-text-pixel-size nil nil t))) 72 ;; I suppose it is as expected because newline is not displayed. (with-temp-buffer (insert "\n") (car (buffer-text-pixel-size nil nil t))) 0 ;; ? (with-temp-buffer (insert "abcd\nef") (car (buffer-text-pixel-size nil nil t))) 48 The doc string of `buffer-text-pixel-size' mentions: "Return size of whole text of BUFFER-OR-NAME in WINDOW." So ,I expect that the last example will return 72px (6 x 12px) + 0px for the newline. But the result is 48px, which means that all the text after the first newline is not counted. This also impacts "string-pixel-width" which is supposed to return the pixel size of the passed string, not part of it: (string-pixel-width "abcdef") => 72 (string-pixel-width "\n") => 0 (string-pixel-width "abcd\nef") => 48 (string-pixel-width "abcd\nef\ngh") => 48 At least this limitation should be mentioned in the doc string? A possible fix for `string-pixel-width' could be to remove all the newlines from the passed string before to call `buffer-text-pixel-size'? Something like this: diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 4cdb065feeb..c68b3b37f9b 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -406,6 +406,11 @@ string-pixel-width face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) (insert string) + ;; Remove newlines. + (forward-line 0) + (while (not (bobp)) + (delete-char -1) + (forward-line 0)) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. (remove-text-properties Thanks! In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) Repository revision: 2ce0d397b12cafcb3e1ac5630bc3fbca61bd6b87 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 40 (KDE Plasma) Configured using: 'configure --with-x-toolkit=gtk3 --with-cairo-xcb --with-native-compilation=no PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_TIME: fr_FR.utf8 value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix ------------=_1725888362-21916-1--