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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 7 Jul 2023 05:13:50 +0300
> Cc: 64420@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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? 

"Fix" in what way?  In most language-environments we get

  (char-width ?…) => 1

What's wrong with that?

> Or does that not match the principle with which those entries are done?

Sorry, I don't understand the question: what principle are you talking
about?

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

It isn't.  The entries in char-width-table are set up when you switch
to the language-environment which requires that; see, for example,
lisp/language/chinese.el where we call set-language-info-alist for any
Chinese-* language-environment.

> >> (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?

Try this:

   (vertical-motion (cons (/ (float PIXELS) (default-font-width)) 0))

where PIXELS is the X coordinate in pixel units.  That is, make the
LINES argument of vertical-motion be a cons cell with its cdr zero and
its car the required horizontal position, a float, in units of the
frame's canonical character width.  vertical-motion works internally
in pixels when considering horizontal coordinates.

Caveat: vertical-motion uses _visual_ columns, relative to the
displayed portion of the line, so it differs from move-to-column when
the line is a continuation line, or is truncated on display, or the
window is hscrolled.