bug#72689: 31.0.50; Proposal to improve string-pixel-width

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 17 Aug 2024 23:12:21 -0700
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 8/17/2024 3:03 PM, David Ponce via Bug reports for GNU Emacs, the 
> Swiss army knife of text editors wrote:
> > I propose the attached patch to make string-pixel-width faster while
> > using less memory, as shown by the following results of a basic
> > benchmark run in emacs -Q to compare the current implementation and this
> > proposal:[snip]
> 
> > -      (insert (propertize string 'line-prefix nil 'wrap-prefix nil))
> > +      (insert string)
> > +      ;; Prefer `remove-text-properties' to `propertize' to avoid
> > +      ;; creating a new string on each call.
> > +      (remove-text-properties
> > +       (point-min) (point-max) '(line-prefix nil wrap-prefix nil))
> 
> Is this change safe?

It's how this function behaved since day one.  These properties are
meaningless for a string's width, since for them to take effect the
string should be at the beginning of a screen line, which is not a
property of an arbitrary string.

> I suppose most of the time, this wouldn't matter, 
> but I could imagine a case where a caller wanted the pixel-width of a 
> string that had one of those properties set, and they'd want those 
> properties to be preserved (e.g. if the string was to be inserted into a 
> buffer later).

If a Lisp program wants to know the width of the line-prefix, it can
do that separately.

> I'm not sure how much this matters, but I always get a bit nervous about 
> a function changing something about one of its arguments when it's not 
> obvious.

The argument isn't changed, only the text inserted into the temporary
buffer gets its properties changed.