GNU bug report logs - #47712
27.1; Provide `string-display-width` function, which takes properties into account, `substring-width`

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mail <at> daniel-mendler.de, 47712 <at> debbugs.gnu.org
Subject: bug#47712: 27.1; Provide `string-display-width` function, which takes properties into account, `substring-width`
Date: Tue, 13 Apr 2021 15:00:35 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  47712 <at> debbugs.gnu.org
> Date: Tue, 13 Apr 2021 10:01:12 +0200
> 
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
> 
> > Note that I would like to have an implementation of
> > `substring-width`/`string-display-width`/`substring-display-width`
> > which does not allocate, since this reduces the GC pressure when
> > formatting many items. How do you think about this?
> >
> > Regarding images, different fonts, maybe a
> > `string-property-pixel-width` would be useful too. But for the use
> > cases I have in mind (formatting monospaced text) computing columns is
> > sufficient.
> 
> Sure; I think a non-allocating function to count monospaced string width
> would be useful.

I won't mount the barricades over this, but please keep in mind that
even with fixed-pitch fonts this will not always produce correct
results, because on GUI frames the "double-width" characters not
always take exactly two columns (it depends on the font).  So this
function will only work reliably on text-mode (a.k.a. TTY) frames and
for Latin characters on GUI frames.

If you still think we should have such a semi-broken function, at
least include some warning in its doc string, so that users wouldn't
be unpleasantly surprised.

Previous Next

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