From: Dmitry Gutov <dmitry@gutov.dev>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 64420@debbugs.gnu.org
Subject: bug#64420: string-width of … is 2 in CJK environments
Date: Tue, 11 Jul 2023 05:13:57 +0300 [thread overview]
Message-ID: <7b8ab44d-f383-4a58-95fa-536db7dd7931@gutov.dev> (raw)
In-Reply-To: <838rbsgrpd.fsf@gnu.org>
On 07/07/2023 09:29, Eli Zaretskii wrote:
>> 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?
It returns 2 in Chinese-BIG5. While the actual metrics of the char don't
change.
>> 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?
The principles by which we fill in the said char-table which we fill "by
hand". E.g. which characters to include, and which to leave with
"automatic" metrics.
>>>> 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.
What I meant is, string-lixel-width must be slower than string-width
because it uses a temp buffer and actual measurements, whereas the
latter function only does a table lookup, more or less (N times).
>>>> (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))
Thank you. I just uses the column values I was already working with. I'm
trying whole-pixelwise addressing in the next version, but the better
precision seems to necessitate a whole new approach, using
string-pixel-width and the space :width display spec. Seems to be
working okay too, in my brief testing.
next prev parent reply other threads:[~2023-07-11 2:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-02 12:57 bug#64420: string-width of … is 2 in CJK environments Dmitry Gutov
2023-07-02 13:10 ` Eli Zaretskii
2023-07-02 13:20 ` Dmitry Gutov
2023-07-02 13:43 ` Eli Zaretskii
2023-07-07 2:13 ` Dmitry Gutov
2023-07-07 6:29 ` Eli Zaretskii
2023-07-11 2:13 ` Dmitry Gutov [this message]
2023-07-11 11:41 ` Eli Zaretskii
2023-07-11 2:23 ` Dmitry Gutov
2023-07-11 11:48 ` Eli Zaretskii
2023-07-11 18:13 ` Dmitry Gutov
2023-07-11 18:45 ` Eli Zaretskii
2023-07-12 1:17 ` Dmitry Gutov
2023-07-12 19:54 ` Dmitry Gutov
2023-07-12 21:11 ` Yuan Fu
2023-07-13 5:23 ` Eli Zaretskii
2023-07-27 1:52 ` Dmitry Gutov
2023-07-14 4:45 ` SUNG TAE KIM
2023-07-14 6:58 ` Eli Zaretskii
2023-07-16 11:51 ` Eli Zaretskii
2023-07-14 9:21 ` SUNG TAE KIM
2023-07-14 11:04 ` Eli Zaretskii
2023-07-14 20:11 ` Yuan Fu
2023-07-16 16:59 ` SUNG TAE KIM
2023-07-16 17:15 ` Eli Zaretskii
2023-08-05 15:01 ` Eli Zaretskii
2023-08-10 21:58 ` Yuan Fu
2023-08-11 5:53 ` Eli Zaretskii
2023-08-11 18:07 ` Yuan Fu
2023-08-11 18:36 ` Eli Zaretskii
2023-08-12 20:18 ` Yuan Fu
2023-08-11 22:34 ` Dmitry Gutov
2023-08-13 0:22 ` Dmitry Gutov
2023-08-13 5:24 ` Eli Zaretskii
2023-08-13 10:48 ` Dmitry Gutov
2023-08-13 12:01 ` Eli Zaretskii
2023-08-13 12:53 ` Dmitry Gutov
2023-08-11 23:52 ` Dmitry Gutov
2023-08-12 5:50 ` Eli Zaretskii
2023-08-12 16:40 ` Dmitry Gutov
2023-08-12 17:09 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b8ab44d-f383-4a58-95fa-536db7dd7931@gutov.dev \
--to=dmitry@gutov.dev \
--cc=64420@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.