From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64420: string-width of =?UTF-8?Q?=E2=80=A6?= is 2 in CJK environments Date: Thu, 13 Jul 2023 08:23:43 +0300 Message-ID: <83ilao5qqo.fsf@gnu.org> References: <961e5083-ccf3-9d39-175d-5c5957130d50@gutov.dev> <83cz1ao3x0.fsf@gnu.org> <83a5weo2dz.fsf@gnu.org> <0c50468b-dec5-c269-7d71-d255ed6d76ae@gutov.dev> <83y1jm7jpb.fsf@gnu.org> <723f6663-b6fc-55f3-0fc9-881c3acdb1d7@gutov.dev> <83fs5u70de.fsf@gnu.org> <2f3f0d49-84fe-0fd3-09be-e4379343e72c@gutov.dev> <62DC36F6-875D-4BFD-8AE8-9F3E1B606FF5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29153"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 64420@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 13 07:24:30 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qJooX-0007QF-SE for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jul 2023 07:24:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJooD-00048X-VW; Thu, 13 Jul 2023 01:24:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJoo6-00048F-7t for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 01:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qJoo5-0001Fw-Vv for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 01:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qJoo5-0006Hv-RT for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 01:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Jul 2023 05:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64420 X-GNU-PR-Package: emacs Original-Received: via spool by 64420-submit@debbugs.gnu.org id=B64420.168922581624135 (code B ref 64420); Thu, 13 Jul 2023 05:24:01 +0000 Original-Received: (at 64420) by debbugs.gnu.org; 13 Jul 2023 05:23:36 +0000 Original-Received: from localhost ([127.0.0.1]:53179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJong-0006HD-5a for submit@debbugs.gnu.org; Thu, 13 Jul 2023 01:23:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJond-0006Gw-Bv for 64420@debbugs.gnu.org; Thu, 13 Jul 2023 01:23:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJonX-0000f2-P2; Thu, 13 Jul 2023 01:23:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=iGf0W0gxZkeq3Eqfp9HicB2bTf7NzIlGc2qfnlljTh0=; b=l0XJ1p1ykiJ9LclttfWl s5UUNW8tGG/dBKkaAyYdzrDdq8H5X27qRkdAJgo63bdbe31z/xiu1VsB1pPuXZmfwXeSmqv/SLVI7 CutaHMU+tbUuCStVnW6IyF/19iuBYlcGQKEeRTvpCMPu9Rp0Ga6r1z7Tu7Jpv+qoe00FRqhc231lu FtesVIX2jbsaE+Ha0U95LK47jEFjHFKz5FmLaktM4uDKK+v4dOWQJ0DP4hHoZ9olRHa1LofnP8wyk oGZ8vGZ4lPJ7jfBX34F8jTendK8t/BmeiaVLjZbfi2KK7XmjJeusZhE0A1Oj10p0WVrPt3BQ6tsDI Oc18tHio/HU+Sw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJonX-0006yl-57; Thu, 13 Jul 2023 01:23:27 -0400 In-Reply-To: <62DC36F6-875D-4BFD-8AE8-9F3E1B606FF5@gmail.com> (message from Yuan Fu on Wed, 12 Jul 2023 14:11:14 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264998 Archived-At: > From: Yuan Fu > Date: Wed, 12 Jul 2023 14:11:14 -0700 > Cc: Eli Zaretskii , > 64420@debbugs.gnu.org > > Here’s what I know: In a CJK “context”, “…” is supposed to be one ideograph wide (like all CJK punctuation), ie, width=2. > > However, it’s not as simple as “they used the wrong font”, because both Latin and CJK use the same Unicode code point for “…”, but expect different glyphs. In publication, this is solved by manually marking the text with style or font, so the software uses the desired glyph. Terminals and editors don’t have this luxury. > > BTW it’s not just ellipses, CJK and Latin shares the same code points for quotes, em dash and middle dot while expecting different glyphs for them. > > Since most terminal and editor (especially terminal) quires ASCII/Latin font before falling back to CJK fonts, I expect most terminal and editor to show the Latin glyph for “…” (width=1) most of the time. > > So practically, it would be correct most of the time if we assume the following code points have a width of 1, regardless of locale: > > – HORIZONTAL ELLIPSIS … > – LEFT/RIGHT DOUBLE QUOTATION MARK “” > – LEFT/RIGHT SINGLE QUOTATION MARK ‘’ > – EM DASH — > – MIDDLE DOT · > > But obviously if someone configures their terminal or editor to use CJK font first, these characters MIGHT have width = 2. I said MIGHT because there are plenty CJK fonts that uses the 1-width Latin glyph for these characters by default. > > It might be helpful to have a wrapper string-width that considers heuristics like this, while string-width goes strictly by Unicode and locale. Thanks. My conclusion from the above is a bit different: we should introduce a user option to modify the behavior of use-cjk-char-width-table, such that users who have fonts where these characters are not double-width could have the width of these characters left at their Unicode values.