From: Jim Porter <jporterbugs@gmail.com>
To: David Ponce <da_vid@orange.fr>, 72689@debbugs.gnu.org
Subject: bug#72689: 31.0.50; Proposal to improve string-pixel-width
Date: Sat, 17 Aug 2024 23:12:21 -0700 [thread overview]
Message-ID: <cbcd9da5-0d5b-b012-51da-187d0a4ff064@gmail.com> (raw)
In-Reply-To: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr>
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.
next prev parent reply other threads:[~2024-08-18 6:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-17 22:03 bug#72689: 31.0.50; Proposal to improve string-pixel-width David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 4:40 ` Eli Zaretskii
2024-08-18 6:05 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 9:15 ` Eli Zaretskii
2024-08-19 8:49 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-20 15:12 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-21 13:17 ` Eli Zaretskii
2024-08-21 20:43 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 3:43 ` Eli Zaretskii
2024-08-22 9:48 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-22 10:59 ` Eli Zaretskii
2024-08-22 14:56 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-23 6:20 ` Juri Linkov
2024-08-23 6:49 ` Eli Zaretskii
2024-08-23 7:23 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-31 8:26 ` Eli Zaretskii
2024-08-31 10:51 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-31 12:00 ` Eli Zaretskii
2024-08-18 6:12 ` Jim Porter [this message]
2024-08-18 7:36 ` David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-18 16:35 ` Jim Porter
2024-08-18 9:23 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cbcd9da5-0d5b-b012-51da-187d0a4ff064@gmail.com \
--to=jporterbugs@gmail.com \
--cc=72689@debbugs.gnu.org \
--cc=da_vid@orange.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.