GNU bug report logs - #72689
31.0.50; Proposal to improve string-pixel-width

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: David Ponce <da_vid <at> orange.fr>, 72689 <at> debbugs.gnu.org
Subject: bug#72689: 31.0.50; Proposal to improve string-pixel-width
Date: Sat, 17 Aug 2024 23:12:21 -0700

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? 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).

Maybe this code could just check for the presence of 'line-prefix' or 
'wrap-prefix' properties and only call 'propertize' if they're in the 
string? (Or maybe it's even possible to leave the string as-is and 
compute the width in some way that accounts for these properties in the 
correct way...)

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.

Previous Next

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