all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.