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

[Eli Zaretskii]

> Date: Tue, 11 Jul 2023 21:13:26 +0300
> Cc: 64420@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> And according to your explanation, we could probably drop the 
> display-graphic-p check since both branches result in the same value on 
> terminal (right?).

You could drop it, yes.  But then string-width is faster, so maybe you
should keep it.

> > Once again, the assumption behind this "feature" of the CJK
> > language-environments is that whoever uses those environments has the
> > terminal emulators configured to use fonts where "…" and its ilk have
> > double size.  Of course, if you just switch language-environment on a
> > system that is otherwise configured for non-CJK locale, the terminal
> > emulator fonts will not magically change, and you get what you see.
> 
> Does "…" actually have double width in some of their fonts?

That's the assumption, yes.  (And not only this one character, you can
see which characters we assume have the same width in the function I
pointed out earlier in this thread, which we run when the
language-environment is switched to something CJK.)  It was definitely
correct at some point in the past, but the big question is whether it
is still correct.  I don't know who can tell us that nowadays.

> This report stems from an issue opened on Github for company-mode (see 
> the first message) from somebody who as I understand hails from one of 
> those countries (I haven't clarified exactly), and they apparently have 
> to work with the "Chinese-BIG5" language environment.
> 
> Are you saying that they misconfigured their system somehow, e.g. that 
> Chinese-BIG5 is expected to be used with a certain set of default system 
> fonts which have "…" at double width?

Either their systems are misconfigured, or the assumption about the
width of those characters is no longer true, at least not in a vast
enough majority of cases.  If we cannot get definitive answers, maybe
we should have an optional feature that disables the redefinition of
char-width for characters that Unicode does not define as "wide", and
then see whether someone still needs such tweaking of char-width.

> > If you worry that something in your package might not work well for
> > some users due to this issue, how about giving them a user-level
> > option to change the char-width of this character to 1?
> 
> It's been suggested that we alter char-width-table dynamically too, as 
> one option. I was just hoping to clarify that we don't carry an 
> erroneous entry for this particular character.

Whether it's "erroneous" or not depends on what fonts are actually
used.  char-width-table cannot know that, so we are guessing there.

> If we did, it would be an easier solution for me to direct the users to 
> the fix in Emacs 29/30, and delay the rollout of the new popup rendering 
> feature a little bit. It will need a fair bit of testing period given 
> the nature of the change.

We will not change the width in Emacs 29: that is too much for a
release branch, definitely at this point in the release cycle.  For
Emacs 30, if we want to change this, I'd rather do it as described
above, leaving the "fire escape" to get back the old behavior.  It
would be nice to hear from as many CJK users as possible which
characters in the widely used fonts are really double-width -- this
will help in the decision what exactly to change in
use-cjk-char-width-table.

> Further, string-pixel-width and buffer-text-pixel-size have only been 
> added in Emacs 29. Any chance you know some replacement I could use to 
> backport the functionality to work in Emacs 25 or 26? 
> buffer-text-pixel-size is defined in C.

You could use window-text-pixel-size instead.