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@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!
