From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Ponce via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines Date: Mon, 9 Sep 2024 14:56:22 +0200 Message-ID: <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> <868qw1vz5d.fsf@gnu.org> Reply-To: David Ponce Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27465"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 73129@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 09 14:57:15 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 1sndxD-0006w6-9R for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 09 Sep 2024 14:57:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sndwx-0007ZT-KC; Mon, 09 Sep 2024 08:56:59 -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 1sndww-0007ZK-P6 for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 08:56:58 -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 1sndww-0002vU-FX for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 08:56:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=gbuRedXSOstkWt6HYSP7HCCkK8tGM4TgdTbOvias5Wo=; b=KH6yWKGMWOvmcoI2oTSWzCDp/ohwD+hybtaY281Rcec5dLLa9woHNGPjuhPWPZvF1ex55HanqbczsCWWy4iuVY2F7aJJdbKZQp5QaG1KkjZJXlMzDWUI3cicW/bKRnmdWzK8UOcPYNm/elwfqpd8FmOW04kJ6XILGFvkEJzPSyW6tnRE9ygSoZcOUI+fDJdcd/RS+trlvOVhw3cujY+aXKF2uxB4NEaNqwQe9BrZcLFEVy5Z0kw1u0bGygGDr8gUyx9iK8knDROtoCoRRPSIdrRZyM33cEqB1nw1SCPQisIs3ByLnNJRhnh2z6u8pJ5Kp93mNaiwDxqypLIDFkIiwg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sndwz-0003tc-Nz for bug-gnu-emacs@gnu.org; Mon, 09 Sep 2024 08:57:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 73129-submit@debbugs.gnu.org id=B73129.172588659414936 (code B ref 73129); Mon, 09 Sep 2024 12:57:01 +0000 Original-Received: (at 73129) by debbugs.gnu.org; 9 Sep 2024 12:56:34 +0000 Original-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 Original-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 Original-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 Content-Language: fr, en-US In-Reply-To: <868qw1vz5d.fsf@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:291500 Archived-At: 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!