GNU bug report logs - #51995
29.0.50; `string-pixel-width' depends on the current window width

Previous Next

Package: emacs;

Reported by: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>

Date: Sat, 20 Nov 2021 05:05:02 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sat, 20 Nov 2021 05:05:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brahimi Saifullah <brahimi.saifullah <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 20 Nov 2021 05:05:02 GMT) Full text and rfc822 format available.

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

From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; `string-pixel-width' depends on the current window width
Date: Sat, 20 Nov 2021 02:04:14 -0300
emacs -Q
(string-pixel-width "foo")
=> 24
(string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo")
=> 744
C-x 3 (or reduce the size of the current window some other way)
(string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo")
=> 481
C-x 3
(string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo")
=> 225
And so on.  The exact values might vary per system.

The problem is that, when the string's width is larger than the windows' width,
the windows' width is returned, and not the string's.
This can be traced back to `window-text-pixel-size', specifically:

| The optional argument X-LIMIT, if non-nil, specifies the maximum X
| coordinate beyond which the text should be ignored.  It is therefore
| also the maximum width that the function can return.  X-LIMIT nil or
| omitted means to use the pixel-width of WINDOW’s body.  This default
| means text of truncated lines wider than the window will be ignored;
| specify a large value for X-LIMIT if lines are truncated and you need
| to account for the truncated text.  Use nil for X-LIMIT if you want to
| know how high WINDOW should become in order to fit all of its buffer’s
| text with the width of WINDOW unaltered.  Use the maximum width WINDOW
| may assume if you intend to change WINDOW’s width.  Since calculating
| the width of long lines can take some time, it’s always a good idea to
| make this argument as small as possible; in particular, if the buffer
| contains long lines that shall be truncated anyway.

In `string-pixel-width', X-LIMIT is nil.

I think the best solution is to modify `window-text-pixel-size' so that
X-LIMIT may be specified as having "no limit".  Y-LIMIT already offers
this possibility: when it is nil, the entirety of the buffer is considered
(in reality, it seems to be simply set to INT_MAX, and that does the job).

--------------------------------------------------------------------------------

I'm experience some different problems with this function, and I'm pretty sure
it don't stem from this same issue, but from WINDOW being buffer.
Should I open a new bug report? Or expand upon the issue on this same thread?



In GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32)
 of 2021-11-19 built on COMPUTADOR
Repository revision: 956f21b6b916f8d87a7b872e02f668883c17b8ba
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19041
System Description: Microsoft Windows 10 Enterprise (v10.0.2004.19041.1348)

Configured using:
 'configure --with-native-compilation --with-json --with-imagemagick
 --without-pop'

Configured features:
ACL DBUS GIF GMP GNUTLS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBXML2
MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XPM ZLIB

Important settings:
  value of $LC_CTYPE: pt_BR.UTF-8
  value of $LANG: PTB
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search seq byte-opt bytecomp byte-compile cconv mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils gv
time-date subr-x help-mode cl-loaddefs cl-lib iso-transl tooltip eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads w32notify dbusbind w32 lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 72646 4855)
 (symbols 48 6899 0)
 (strings 32 21630 1558)
 (string-bytes 1 703288)
 (vectors 16 14099)
 (vector-slots 8 298463 13452)
 (floats 8 26 261)
 (intervals 56 234 3)
 (buffers 992 10))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sat, 20 Nov 2021 07:21:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50;
 `string-pixel-width' depends on the current window width
Date: Sat, 20 Nov 2021 09:20:51 +0200
> From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
> Date: Sat, 20 Nov 2021 02:04:14 -0300
> 
> 
> emacs -Q
> (string-pixel-width "foo")
> => 24
> (string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo")
> => 744
> C-x 3 (or reduce the size of the current window some other way)
> (string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo")
> => 481
> C-x 3
> (string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo")
> => 225
> And so on.  The exact values might vary per system.
> 
> The problem is that, when the string's width is larger than the windows' width,
> the windows' width is returned, and not the string's.

Why is it useful to measure width of a string that is wider than the
window?  Isn't it enough to know that the string is wider than the
window in that case?  (This part is not currently documented, but
documenting it is easy.)  What is the actual real-life situation where
this is needed?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sat, 20 Nov 2021 08:49:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>, 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50; `string-pixel-width' depends on the current
 window width
Date: Sat, 20 Nov 2021 09:48:39 +0100
> I think the best solution is to modify `window-text-pixel-size' so that
> X-LIMIT may be specified as having "no limit".  Y-LIMIT already offers
> this possibility: when it is nil, the entirety of the buffer is considered
> (in reality, it seems to be simply set to INT_MAX, and that does the job).

Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is
not a good idea to set X-LIMIT or Y-LIMIT to very large values.  The
doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT
that

  Since calculating the width of long lines can take some time, it's
  always a good idea to make this argument as small as possible; in
  particular, if the buffer contains long lines that shall be truncated
  anyway.

and about Y-LIMIT that

  Since calculating the text height of a large buffer can take some time,
  it makes sense to specify this argument if the size of the buffer is
  large or unknown.

So any such fix has to be made in 'string-pixel-width' itself.

> I'm experience some different problems with this function, and I'm pretty sure
> it don't stem from this same issue, but from WINDOW being buffer.
> Should I open a new bug report? Or expand upon the issue on this same thread?

'string-pixel-width' and the accompanying change of
'window-text-pixel-size' are broken in many ways, see also

  https://mail.gnu.org/archive/html/emacs-devel/2021-11/msg00339.html

If you see a problem that is not mentioned there, please tell us.

I hopefully fixed most of the issues here but cannot send you a patch at
the moment to test because my local copy is completely out of synch with
master.  So please bear with me.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sat, 20 Nov 2021 09:37:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51995 <at> debbugs.gnu.org, Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
Subject: Re: bug#51995: 29.0.50; `string-pixel-width' depends on the current
 window width
Date: Sat, 20 Nov 2021 10:35:56 +0100
martin rudalics <rudalics <at> gmx.at> writes:

>   Since calculating the text height of a large buffer can take some time,
>   it makes sense to specify this argument if the size of the buffer is
>   large or unknown.
>
> So any such fix has to be made in 'string-pixel-width' itself.

Yup.  Finding an appropriate limit to use here isn't trivial, though.
But I guess we could just use something very large, or add an optional
parameter to 'string-pixel-width' to allow the caller to control it...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sat, 20 Nov 2021 21:38:02 GMT) Full text and rfc822 format available.

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

From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50;
 `string-pixel-width' depends on the current window width
Date: Sat, 20 Nov 2021 18:36:46 -0300
>What is the actual real-life situation where
>this is needed?
Mainly when a window with delicated alignment is resized.
Indeed, in most situations it likely won't be an issue,
but I can think of times when it most definitely will:

For example, in the package I'm working on,
I want certain text to always be centered,
even if the user resizes the window.

(By centered I mean having the same amount of space on both sides).

This is a mockup of the code I use:

(let* ((string "Hello World, Hello World, Hello world")
       (width (string-pixel-width string)))
  (insert
   (propertize " "
               'display
               `(space :align-to (- center (,(/ width 2)))))
   string))

If you evaluate this code in a window that is bigger or equal
to the size of the string, it will be properly aligned even if
you resize it later.  But if you evaluate it in a small window,
it will be grossly misaligned when you increase the window size.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sat, 20 Nov 2021 21:43:02 GMT) Full text and rfc822 format available.

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

From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50;
 `string-pixel-width' depends on the current window width
Date: Sat, 20 Nov 2021 18:42:01 -0300
>Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is
>not a good idea to set X-LIMIT or Y-LIMIT to very large values.  The
>doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT
>that
>
>   Since calculating the width of long lines can take some time, it's
>   always a good idea to make this argument as small as possible; in
>   particular, if the buffer contains long lines that shall be truncated
>   anyway.

I saw the warnings, but I'm unsure of their validity.
Here are some benchmarks that I did.  Each form was run on a fresh emacs -Q.
Apologies in advance if there is something wrong about them:

;;; X-LIMIT nil (window width is the limit)
(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "foo")
      (car (window-text-pixel-size nil (point-min) (point))))))
;; (15.551981 588 8.272839)

(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
      (car (window-text-pixel-size nil (point-min) (point))))))
;; (17.975419000000002 588 8.30243)


;;; X-LIMIT is equal to the width of the string plus 1
(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "foo")
      (car (window-text-pixel-size nil (point-min) (point) 25)))))
;; (15.489861 587 8.267005000000001)

(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
      (car (window-text-pixel-size nil (point-min) (point) 873)))))
;; (17.98802 587 8.421413)


;;; X-LIMIT is unreasonably large
(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "foo")
      (car (window-text-pixel-size nil (point-min) (point) 1000000)))))
;; (15.508047000000001 587 8.281872)

(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
      (car (window-text-pixel-size nil (point-min) (point) 1000000)))))
;; (18.031506 588 8.440261)

The limit actually seems to be rather irrelevant.
Long strings take expectedly longer, but it doesn't
seem related to how big or how small X-LIMIT is.

The following use a buffer as WINDOW,
as `string-pixel-width' currently does:

(benchmark-run 100000
  (with-temp-buffer
    (insert "foo")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point)))))
;; (5.935459 164 2.328032)

(benchmark-run 100000
  (with-temp-buffer
    (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point)))))
;; (8.362771 168 2.349145)


(benchmark-run 100000
  (with-temp-buffer
    (insert "foo")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 25))))
;; (5.922218 164 2.350169)

(benchmark-run 100000
  (with-temp-buffer
    (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 873))))
;; (7.989145 164 2.2566439999999997)


(benchmark-run 100000
  (with-temp-buffer
    (insert "foo")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 1000000))))
;; (5.933362 168 2.378873)

(benchmark-run 100000
  (with-temp-buffer
    (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 1000000))))
;; (8.006855 167 2.318854)

It's a lot more efficient to use a buffer, but the difference
between the limits themselves continue to be insignificant.

--------------------------------------------------------------------------------

>'string-pixel-width' and the accompanying change of
>'window-text-pixel-size' are broken in many ways, see also
>
>   https://mail.gnu.org/archive/html/emacs-devel/2021-11/msg00339.html
>
>If you see a problem that is not mentioned there, please tell us.

Yes, those seem to be the exact problems I was experiencing.

>I hopefully fixed most of the issues here but cannot send you a patch at
>the moment to test because my local copy is completely out of synch with
>master.  So please bear with me.

Take your time :)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sun, 21 Nov 2021 06:35:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
Cc: rudalics <at> gmx.at, 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50;
 `string-pixel-width' depends on the current window width
Date: Sun, 21 Nov 2021 08:34:34 +0200
> Date: Sat, 20 Nov 2021 18:42:01 -0300
> From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
> Cc: 51995 <at> debbugs.gnu.org
> 
> >Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is
> >not a good idea to set X-LIMIT or Y-LIMIT to very large values.  The
> >doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT
> >that
> >
> >   Since calculating the width of long lines can take some time, it's
> >   always a good idea to make this argument as small as possible; in
> >   particular, if the buffer contains long lines that shall be truncated
> >   anyway.
> 
> I saw the warnings, but I'm unsure of their validity.
> Here are some benchmarks that I did.  Each form was run on a fresh emacs -Q.
> Apologies in advance if there is something wrong about them:
> 
> ;;; X-LIMIT nil (window width is the limit)
> (benchmark-run 100000
>   (save-window-excursion
>     (with-temp-buffer
>       (set-window-buffer nil (current-buffer))
>       (insert "foo")
                 ^^^
He mean a REALLY long line.  Like thousands of characters.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sun, 21 Nov 2021 09:13:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50; `string-pixel-width' depends on the current
 window width
Date: Sun, 21 Nov 2021 10:12:40 +0100
[Message part 1 (text/plain, inline)]
> I saw the warnings, but I'm unsure of their validity.
> Here are some benchmarks that I did.  Each form was run on a fresh emacs -Q.
> Apologies in advance if there is something wrong about them:
[...]
> (benchmark-run 100000
>    (with-temp-buffer
>      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
>      (car (window-text-pixel-size
>            (current-buffer) (point-min) (point) 1000000))))
> ;; (8.006855 167 2.318854)
>
> It's a lot more efficient to use a buffer, but the difference
> between the limits themselves continue to be insignificant.

These examples are harmless.  Please try to test (1) with a large buffer
that has no newline characters and (2) with 'truncate-lines' non-nil.
'window-text-pixel-size' must be able to handle these cases gracefully
even if it's not geared to them.

Any clients of 'window-text-pixel-size' like 'string-pixel-width' can
easily set X-LIMIT to some sufficiently large value without affecting
the basic functionality of 'window-text-pixel-size'.

>> I hopefully fixed most of the issues here but cannot send you a patch at
>> the moment to test because my local copy is completely out of synch with
>> master.  So please bear with me.

Please try the attached patch (if it doesn't apply, I'll send you the
affected functions separately so you can apply the changes manually).

Thanks, martin
[buffer-text-pixel-size.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Sun, 21 Nov 2021 18:39:02 GMT) Full text and rfc822 format available.

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

From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50;
 `string-pixel-width' depends on the current window width
Date: Sun, 21 Nov 2021 15:38:05 -0300
>He mean a REALLY long line.  Like thousands of characters.

>These examples are harmless.  Please try to test (1) with a large buffer
>that has no newline characters and (2) with 'truncate-lines' non-nil.
>'window-text-pixel-size' must be able to handle these cases gracefully
>even if it's not geared to them.

I think there's a misunderstading.
I meant that a facility should be added to `window-text-pixel-size' so
that callers like `string-pixel-width' can ask for having no (X) limit
without specifying a large number themselves.  Basically I want to use:

  (window-text-pixel-size window (point-min) (point) t)
                                                    ^^^
   (or some other value that `window-text-pixel-size' 
   should understand as meaning "no limit" for X-LIMIT)

instead of:

  (window-text-pixel-size window (point-min) (point) 123456789)

The default behavior of the function should stay the same.

>Any clients of 'window-text-pixel-size' like 'string-pixel-width' can
>easily set X-LIMIT to some sufficiently large value without affecting
>the basic functionality of 'window-text-pixel-size'.

Yes, that's the simplest solution, but I find passing a random magic number
instead of providing a simple interface to say "I don't want to use a limit"
(like Y-LIMIT already allows, as I previously mentioned) rather inelegant :)

>Please try the attached patch (if it doesn't apply, I'll send you the
>affected functions separately so you can apply the changes manually).

Can you explain how you are supposed to apply it?

I tried:

  git apply buffer-text-pixel-size.diff

But all it says is:

  error: corrupt patch at line 12

I did apply the changes manually by looking at the .diff file,
and it's seemingly working for me.  Minus one glaring issue:
`string-pixel-width' is using `buffer-size' as the X-LIMIT, but
that function returns the amount of characters in the buffer.
This means that instead of returning the pixel width, it merely
returns the amount of characters in a string.  If I change that,
everything else seems to be in good order.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Mon, 22 Nov 2021 00:54:02 GMT) Full text and rfc822 format available.

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

From: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50;
 `string-pixel-width' depends on the current window width
Date: Sun, 21 Nov 2021 21:53:27 -0300
>Can you explain how you are supposed to apply it?
>
>I tried:
>
>  git apply buffer-text-pixel-size.diff
>
>But all it says is:
>
>  error: corrupt patch at line 12

My bad, it seems the file got corrupted on my end.  I downloaded it from
debbugs.gnu.org and the patch is recognized as valid, yet it does not apply:

  Checking patch lisp/emacs-lisp/subr-x.el...
  error: while searching for:
    "Return the width of STRING in pixels."
    (with-temp-buffer
      (insert string)
      (car (window-text-pixel-size
            (current-buffer) (point-min) (point)))))

  (provide 'subr-x)


  error: patch failed: lisp/emacs-lisp/subr-x.el:446
  error: lisp/emacs-lisp/subr-x.el: patch does not apply


(The only problem is that a new function was added at
 the end of subr-x,  the xdisp.c part does apply fine.)

I've also tested the patch further, using `buffer-text-size' on my
package's implementation of `string-pixel-width', and everything is
is working, including my tests.  Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Mon, 22 Nov 2021 09:30:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Brahimi Saifullah <brahimi.saifullah <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 51995 <at> debbugs.gnu.org
Subject: Re: bug#51995: 29.0.50; `string-pixel-width' depends on the current
 window width
Date: Mon, 22 Nov 2021 10:28:48 +0100
[Message part 1 (text/plain, inline)]
> I meant that a facility should be added to `window-text-pixel-size' so
> that callers like `string-pixel-width' can ask for having no (X) limit
> without specifying a large number themselves.  Basically I want to use:
>
>    (window-text-pixel-size window (point-min) (point) t)
>                                                      ^^^
>     (or some other value that `window-text-pixel-size'
>     should understand as meaning "no limit" for X-LIMIT)
>
> instead of:
>
>    (window-text-pixel-size window (point-min) (point) 123456789)
>
> The default behavior of the function should stay the same.

OK.

>> Any clients of 'window-text-pixel-size' like 'string-pixel-width' can
>> easily set X-LIMIT to some sufficiently large value without affecting
>> the basic functionality of 'window-text-pixel-size'.
>
> Yes, that's the simplest solution, but I find passing a random magic number
> instead of providing a simple interface to say "I don't want to use a limit"
> (like Y-LIMIT already allows, as I previously mentioned) rather inelegant :)

Agreed (also because 'most-positive-fixnum' and anything beyond INT_MAX
as argument don't work at the moment which is confusing).

> Minus one glaring issue:
> `string-pixel-width' is using `buffer-size' as the X-LIMIT, but
> that function returns the amount of characters in the buffer.
> This means that instead of returning the pixel width, it merely
> returns the amount of characters in a string.  If I change that,
> everything else seems to be in good order.

Yes.  This wasn't a very bright idea.  The function will now be

(defun string-pixel-width (string)
  "Return the width of STRING in pixels."
  (with-temp-buffer
    (insert string)
    (car (buffer-text-pixel-size nil nil t))))

as you suggested.  The xdisp.c change is attached.  Apply the
'string-pixel-width' change manually.

Thanks, martin
[buffer-text-pixel-size.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51995; Package emacs. (Mon, 22 Nov 2021 11:05:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51995 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Brahimi Saifullah <brahimi.saifullah <at> gmail.com>
Subject: Re: bug#51995: 29.0.50; `string-pixel-width' depends on the current
 window width
Date: Mon, 22 Nov 2021 12:04:35 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> Yes.  This wasn't a very bright idea.  The function will now be
>
> (defun string-pixel-width (string)
>   "Return the width of STRING in pixels."
>   (with-temp-buffer
>     (insert string)
>     (car (buffer-text-pixel-size nil nil t))))
>
> as you suggested.  The xdisp.c change is attached.  Apply the
> 'string-pixel-width' change manually.

Thanks; I've now applied the patch and adjusted the function, and it
seems to work as advertised now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 29.1, send any further explanations to 51995 <at> debbugs.gnu.org and Brahimi Saifullah <brahimi.saifullah <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 22 Nov 2021 11:06:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 20 Dec 2021 12:24:14 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 89 days ago.

Previous Next


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