GNU bug report logs - #73129
31.0.50; buffer-text-pixel-size vs. newlines

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73129 in the body.
You can then email your comments to 73129 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Ponce <da_vid <at> orange.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; buffer-text-pixel-size vs. newlines
Date: Mon, 9 Sep 2024 00:22:11 +0200

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

Message #8 received at 73129 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 73129 <at> debbugs.gnu.org
Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines
Date: Mon, 09 Sep 2024 14:34:38 +0300

> 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" <bug-gnu-emacs <at> gnu.org>
> 
> 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?

Message #11 received at 73129 <at> debbugs.gnu.org (full text, mbox):

From: David Ponce <da_vid <at> orange.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73129 <at> debbugs.gnu.org
Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines
Date: Mon, 9 Sep 2024 14:56:22 +0200

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" <bug-gnu-emacs <at> gnu.org>
>>
>> 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!

Message #16 received at 73129-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 73129-done <at> debbugs.gnu.org
Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines
Date: Mon, 09 Sep 2024 16:25:07 +0300

> Date: Mon, 9 Sep 2024 14:56:22 +0200
> Cc: 73129 <at> debbugs.gnu.org
> From: David Ponce <da_vid <at> orange.fr>
> 
> > 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.

Previous Next

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