GNU bug report logs - #63029
[BUG?] format inconsistency in deciding string widths on different locales

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ruijie Yu <ruijie <at> netyu.xyz>
Subject: bug#63029: closed (Re: bug#63029: [BUG?] format inconsistency in
 deciding string widths on different locales)
Date: Sun, 23 Apr 2023 14:40:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#63029: [BUG?] format inconsistency in deciding string widths on different locales

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 63029 <at> debbugs.gnu.org.

-- 
63029: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63029
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ruijie Yu <ruijie <at> netyu.xyz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63029-done <at> debbugs.gnu.org
Subject: Re: bug#63029: [BUG?] format inconsistency in deciding string
 widths on different locales
Date: Sun, 23 Apr 2023 22:38:33 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> OK, so can we close this issue?

We can -- done.

> Btw, the recommended method of computing the width of a string is via
> string-pixel-width.

Will take a look at this function.  Thanks.

-- 
Best,


RY

[Please note that this mail might go to spam due to some
misconfiguration in my mail server -- still investigating.]

[Message part 3 (message/rfc822, inline)]

From: Ruijie Yu <ruijie <at> netyu.xyz>
To: bug-gnu-emacs <at> gnu.org
Subject: [BUG?] format inconsistency in deciding string widths on different
 locales
Date: Sun, 23 Apr 2023 18:23:02 +0800

Hello,

I don't quite know yet whether this is a bug in Emacs.  Here are the
observed results, and note the unicode character:

--8<---------------cut here---------------start------------->8---
$ for locale in {en_US,fr_FR,de_DE,zh_CN,ja_JA}.UTF-8; do
    printf "$locale\t"
    LANG="$locale" src/emacs -Q -batch \
                   -eval '(message "%S" (format "%-5.5s" "1234…"))'
done
--8<---------------cut here---------------end--------------->8---

This results in the following output:

--8<---------------cut here---------------start------------->8---
en_US.UTF-8	"1234…"
fr_FR.UTF-8	"1234…"
de_DE.UTF-8	"1234…"
zh_CN.UTF-8	"1234 "
ja_JA.UTF-8	"1234 "
--8<---------------cut here---------------end--------------->8---

Notice that in zh_CN and ja_JA, we have a space instead of the expected
ellipsis character.


If this is expected behavior, how do we know how "wide" the `format'
function thinks any given character is?  In other words, why _does_ it
think "…" should be two-character wide?  And how do we, the elisp users,
get this information?  I tried to dive into the C code for
`styled_format', but got lost.  Thanks.

----------

Reproduced on this in-source build:

In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.17.8) of 2023-04-23 built on fw.net.yu
Repository revision: 3badd2358d5f0af71887ee1cc9d39c2f312b6888
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --sysconfdir=/etc --prefix=/usr --localstatedir=/var
 --with-cairo --with-harfbuzz --with-libsystemd --with-modules
 --with-pgtk --with-native-compilation CFLAGS=-Og'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

-- 
Best,


RY

[Please note that this mail might go to spam due to some
misconfiguration in my mail server -- still investigating.]

Previous Next

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