From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines Date: Mon, 09 Sep 2024 14:34:38 +0300 Message-ID: <868qw1vz5d.fsf@gnu.org> References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1245"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73129@debbugs.gnu.org To: David Ponce Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 09 13:35:24 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sncg0-0000BY-Am for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 09 Sep 2024 13:35:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sncfd-0001OL-Vx; Mon, 09 Sep 2024 07:35:02 -0400 Original-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 1sncfc-0001O2-C9 for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 07:35:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sncfc-0000qa-2x for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 07:35:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=7Uu8oiTo2/AJSvHTX76jY/IyxJy2DhIaagACPV8Aahs=; b=vZsyR0sNc1Gb+gKvBpNfDBELMuxskFdQMrpK52c1vls5OLJyG4E6JnUry/j5KNkwMaYIQa8MOllStZfQ9aCD8ympGB6sCxviKWpBf1+AYMEb5YtxEjheU1s8oDdtrqD1ZR2zkkq+QBDiLZwnv8FXG/MmEl+Jfp106IB9GDGwsYj3ZQLCjV56XLhbPlw+QD6XU3Jd/Am6WiOn+3nn49mgDAr5x7ezb+9d/+B9aJ8HoPjNmxX3yucMep3sdDAaun2bLh0pYQuxOxeryR9T/jHMidEklvP8vK18ozg2uZdp631599BpdFzPKEePLqxlANep6iJ2YhUgk8fDRqtG6F4fWw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sncfe-0007y8-HA for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 07:35:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 73129-submit@debbugs.gnu.org id=B73129.172588169430609 (code B ref 73129); Mon, 09 Sep 2024 11:35:02 +0000 Original-Received: (at 73129) by debbugs.gnu.org; 9 Sep 2024 11:34:54 +0000 Original-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 Original-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 Original-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==; In-Reply-To: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> (bug-gnu-emacs@gnu.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291495 Archived-At: > 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?