GNU bug report logs -
#64420
string-width of … is 2 in CJK environments
Previous Next
Full log
Message #17 received at 64420 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
On 02/07/2023 16:43, Eli Zaretskii wrote:
>> Is there some inherent reason why string-width differs from the result
>> of the above expression
> Because string-width doesn't consult the actual metrics of the font.
> It uses a char-table that we set "by hand".
Would it be appropriate to fix the entry for … in that table either way?
Or does that not match the principle with which those entries are done?
>> and especially only does that on CJK?
> In CJK locales, most characters are double-width because those locales
> use fonts where the glyphs are wider. Or at least this is the theory.
> string-pixel-width is free from these assumptions because it actually
> measures the font glyphs.
I'm guessing it's somewhat slower because of that too, but that doesn't
seem like a problem so far.
>> Since the overlay-based popup is used on both GUI and Terminal frames,
>> are you suggesting I define my own string-width like this?
>>
>> (defun company--string-width (str)
>> (if (display-graphic-p)
>> (ceiling (/ (string-pixel-width str)
>> (float (default-font-width))))
>> (string-width str)))
> Yes, definitely. (Actually, display-multi-font-p is better than
> display-graphic-p, but in practice they will return the same value.)
Could you suggest a similar alternative to move-to-column? It's not 100%
necessary, but we also have a piece of code where we take a width-aware
substring from a buffer. And that logic uses 'move-to-column', which
also has a problem with … in "Chinese-BIG5".
This bug report was last modified 2 years and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.