GNU bug report logs - #64420
string-width of … is 2 in CJK environments

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dmitry <at> gutov.dev>

Date: Sun, 2 Jul 2023 12:58:02 UTC

Severity: normal

Full log


Message #125 received at 64420 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: itaemu <at> gmail.com, casouri <at> gmail.com, 64420 <at> debbugs.gnu.org
Subject: Re: bug#64420: string-width of … is 2 in CJK environments
Date: Sun, 13 Aug 2023 15:53:04 +0300
On 13/08/2023 15:01, Eli Zaretskii wrote:
>> Date: Sun, 13 Aug 2023 13:48:42 +0300
>> Cc: casouri <at> gmail.com, itaemu <at> gmail.com, 64420 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>>> So the point here would be that some "ambiguous" ones are still wider
>>>> than 1, I guess.
>>> According to Yuan, at least in his environment those characters have a
>>> width that is closer to 2 than to 1.  In which case using 2 would
>>> produce better alignment.  Of course, using string-pixel-width will
>>> produce an even better alignment.
>>
>> In GUI, that is. But if they are displayed with width 1 in terminal, we
>> better make string-width return 1 for them too.
> 
> Yes.  But it turns out that how wide these characters are on TTY
> frames depends on the terminal emulator and its own options regarding
> those characters.  So some users will want the value 1 and others will
> want the value 2, depending on which terminals they use and what
> options of those terminals they like best.

That's where having the option that we just added will be beneficial. As 
opposed to, say, changing the behavior outright.

> The important part is that the Emacs's notion of the character width
> is consistent with that of the terminal.
> 
>> That might be slightly worse for certain applications (like popup in
>> company), but at least the basic rendering and navigation bugs in
>> terminal will be fixed this way. And the new popup rendering for company
>> (using string-width and spacing instructions) is close to being ready
>> anyway.
> 
> Yes, sure.  There's no doubt on my side that this option is useful;
> I'm just trying to collect data that would allow us to decide on the
> best default value, that's all.

Yuan seems to be saying that iTerm2, at least, defaults to showing the 
ambiguous chars at width 1 and issues a warning when the user tries to 
change that option.

gnome-terminal also has that default. I just checked on my machine 
(Ubuntu from 2022), and the description in this bug report from 2015 
also says that: https://bugzilla.gnome.org/show_bug.cgi?id=749414, so 
the default is not new.

Others are welcome to report their experience.

I've found a couple of conflicting reports regarding Microsoft Terminal, 
someone could test that too.




This bug report was last modified 2 years ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.