unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Mendler <mail@daniel-mendler.de>
Cc: 47712@debbugs.gnu.org
Subject: bug#47712: 27.1; Provide `string-display-width` function, which takes properties into account, `substring-width`
Date: Mon, 12 Apr 2021 16:21:15 +0300	[thread overview]
Message-ID: <83im4r3agk.fsf@gnu.org> (raw)
In-Reply-To: <1c8f7066-3da2-d960-11e7-a42f567432bd@daniel-mendler.de> (message from Daniel Mendler on Mon, 12 Apr 2021 14:50:25 +0200)

> Cc: 47712@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 12 Apr 2021 14:50:25 +0200
> 
> On 4/12/21 2:21 PM, Eli Zaretskii wrote:
> > That is easy to work around, right?  Just insert the string into a
> > temporary buffer and say with-current-buffer (and/or
> > with-selected-window, if needed).
> 
> I have not tested this but I suspect this to be slow for a few thousand 
> strings.

Can we please see both methods benchmarked?  I'd also like to
understand better in which situation you need to do this with
thousands of strings in one go.  In any case, I presume that running
your code on thousands of strings also takes some time, let alone
conses many strings.

> > In general, calculating a string's width out of display context is
> > meaningless in Emacs.  More about that below.
> 
> I know about the context dependence. But there is the `string-width` 
> function which is also computed in the current context. I am only asking 
> for an improved version of already existing functionality. My most 
> minimal feature request is just a function `substring-width`.

string-width is from my POV a historical accident.  The accident
happened long ago enough to preclude deleting it, but I'd like to
limit its use as much as possible.  I certainly would like to avoid
extending it or making it support more features (it currently supports
only composed characters).

> However if you attack `string-width` for not computing something 
> correct, then one may want to consider deprecating `string-width` 
> altogether or at least make it clear in the documentation that this 
> function should not be used and something else based on the window 
> function should be used instead.

I'm fine with doing that, of course.





  reply	other threads:[~2021-04-12 13:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-11 21:16 bug#47712: 27.1; Provide `string-display-width` function, which takes properties into account, `substring-width` Daniel Mendler
2021-04-12  2:26 ` Eli Zaretskii
2021-04-12  8:45   ` Daniel Mendler
2021-04-12  8:53     ` Lars Ingebrigtsen
2021-04-12  9:08       ` Daniel Mendler
2021-04-13  8:01         ` Lars Ingebrigtsen
2021-04-13 12:00           ` Eli Zaretskii
2021-04-13 12:25             ` Daniel Mendler
2021-04-14  8:50               ` Eli Zaretskii
2021-04-14 10:49                 ` Daniel Mendler
2021-04-14 11:38                   ` Eli Zaretskii
2021-04-12 12:21     ` Eli Zaretskii
2021-04-12 12:50       ` Daniel Mendler
2021-04-12 13:21         ` Eli Zaretskii [this message]
2021-04-12 13:32           ` Daniel Mendler
2021-04-12 13:40             ` Eli Zaretskii
2021-04-12 14:05               ` Daniel Mendler
2021-04-12 14:15                 ` Eli Zaretskii
2021-04-12 14:32                   ` Eli Zaretskii
2021-04-12 14:38                     ` Daniel Mendler
2021-04-12 17:01                       ` Eli Zaretskii
2021-04-12 17:18                         ` Daniel Mendler
2021-04-13  7:06                         ` martin rudalics
2021-04-13 12:23                           ` Eli Zaretskii
2021-04-12 14:36                   ` Daniel Mendler
2021-04-12 17:09                     ` Eli Zaretskii
2021-04-12 17:13                       ` Daniel Mendler

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83im4r3agk.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=47712@debbugs.gnu.org \
    --cc=mail@daniel-mendler.de \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).