bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47712: 27.1; Provide `string-display-width` function, which takes pr


From: Eli Zaretskii
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

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]