[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64420: string-width of … is 2 in CJK environments
From: |
Eli Zaretskii |
Subject: |
bug#64420: string-width of … is 2 in CJK environments |
Date: |
Fri, 07 Jul 2023 09:29:18 +0300 |
> 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.
- bug#64420: string-width of … is 2 in CJK environments, Dmitry Gutov, 2023/07/02
- bug#64420: string-width of … is 2 in CJK environments, Dmitry Gutov, 2023/07/10
- bug#64420: string-width of … is 2 in CJK environments, Eli Zaretskii, 2023/07/11
- bug#64420: string-width of … is 2 in CJK environments, Dmitry Gutov, 2023/07/11
- bug#64420: string-width of … is 2 in CJK environments, Eli Zaretskii, 2023/07/11
- bug#64420: string-width of … is 2 in CJK environments, Dmitry Gutov, 2023/07/11
- bug#64420: string-width of … is 2 in CJK environments, Dmitry Gutov, 2023/07/12
- bug#64420: string-width of … is 2 in CJK environments, Yuan Fu, 2023/07/12
- bug#64420: string-width of … is 2 in CJK environments, Eli Zaretskii, 2023/07/13