bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Tue, 11 Jul 2023 14:48:16 +0300

> Date: Tue, 11 Jul 2023 05:23:03 +0300
> Cc: 64420@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 02/07/2023 16:43, Eli Zaretskii wrote:
> >> Since the overlay-based popup is used on both GUI and Terminal frames,
> >> are you suggesting I define my own string-width like this?
> >>
> >> (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.)
> 
> Regarding this approach, though: it seems to fail in my terminal Emacs.

string-pixel-width is useless on TTY frames, because Emacs cannot
access the metrics of the characters on those frames.  In those cases
string-pixel-width falls back to use char-width, and you get the same
result.

> Meaning, when I'm testing the feature using 'emacs -nw' (inside e.g. 
> gnome-terminal), both (string-pixel-width "…") and (string-width "…") 
> return 2. Whereas the character on display looks 1-character wide even 
> there.

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.

> More than that, moving the cursor close to that character with C-f or 
> C-b creates odd effects like the cursor jumping one position to the 
> left, or a char being rendered twice at a certain position on the same 
> line to the right of it (after I move the cursor there past the … char), 

Yes, because we lie to the display engine about the character 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]