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

[Dmitry Gutov]

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