Subject: Re: bug#64420: string-width of … is 2 in CJK environments

From: Dmitry Gutov <[email-masked]>
Date: Fri, 7 Jul 2023 05:13:50 +0300

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".