From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#64420: string-width of =?UTF-8?Q?=E2=80=A6?= is 2 in CJK environments Date: Wed, 12 Jul 2023 04:17:03 +0300 Message-ID: <2f3f0d49-84fe-0fd3-09be-e4379343e72c@gutov.dev> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30515"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cc: 64420@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 12 03:18:21 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 1qJOUm-0007hN-LP for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Jul 2023 03:18:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJOUW-0002m6-UR; Tue, 11 Jul 2023 21:18:04 -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 1qJOUV-0002lg-4E for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2023 21:18:03 -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 1qJOUU-0003yb-Sc for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2023 21:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qJOUU-0003XD-8H for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2023 21:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Jul 2023 01:18:02 +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.168912463713538 (code B ref 64420); Wed, 12 Jul 2023 01:18:02 +0000 Original-Received: (at 64420) by debbugs.gnu.org; 12 Jul 2023 01:17:17 +0000 Original-Received: from localhost ([127.0.0.1]:51242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJOTl-0003WI-8s for submit@debbugs.gnu.org; Tue, 11 Jul 2023 21:17:17 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:45767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJOTg-0003W2-FW for 64420@debbugs.gnu.org; Tue, 11 Jul 2023 21:17:16 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 357045C00EF; Tue, 11 Jul 2023 21:17:07 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 11 Jul 2023 21:17:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689124627; x=1689211027; bh=u1OBVRrm8sVMhfnuNru7CZIFB/AqnnTRazC j1Wsgb0g=; b=Cbxvpy1kaTwYEVZrGGJxJRVp2f86s9mLas3HpBPEh8EsXerwO9x XjfZR/xl4cf8Fi+EBIaiOkOC5Mj47dzhRmdZVZmdYjbw7w5H5L0o+bhtWsjQikCF FtBwuFeT9/qWtX8EMVpcHskSMKM0dG/ZAPtxZiw6vuNZP+qVznbihaGt1vcs/qKW PZXa0tnJq3OOnPXH2BB3QVjSmJXqhfTFRtbyeBbpxRT6YmZom9XPIudTsSIj9nhp VKXNLbMGJiLW3ZlDpTXoAUNV+hwLMGEMQmIy3pUhneGPUzbqMDGpF5hfxNqiyeZn sbhSeSMqDGlbdrwInLIZNTJoPhfiKlNtJjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1689124627; x=1689211027; bh=u1OBVRrm8sVMhfnuNru7CZIFB/AqnnTRazC j1Wsgb0g=; b=BvkB2u3dG/rR9XTDtZILYvpgOTCPd8dK0zpzj2VGLmrhcxP/SEy T9ov/Z1W0YWlzyM/+eZtwWlBLqzCap83lmfTie2xvFaswTKlRz22TElpEy/lUQ77 fag72c80AwddCyOfwYxUk70Ubc7oEZwnaVT3+BrkWZyPuQ3cTAgWMu9qXdUQBdak hSZzFXSp/KhFygdnwgAw3etYvRab6JkjaWhNXI/zgkrKBD5yNzOYuSNqceccmLZ0 e3VvrB35pSmNownX37eiSfWErOYc+1wcMB0R2bf0eNDP8EzjW3HRlkI247sVXtMm sCOaXtTv0OmMUWx4e2QBAh7ZPZyScpPS6Nw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrfedugdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jul 2023 21:17:05 -0400 (EDT) Content-Language: en-US In-Reply-To: <83fs5u70de.fsf@gnu.org> 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:264948 Archived-At: On 11/07/2023 21:45, Eli Zaretskii wrote: >>> 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. Whole ranges of characters, I see. >> 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. All right. I'll try to get more info from the issue reporter, at least. >> 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. Either I'm doing something wrong, or this function's behavior was different in Emacs 28. There had been some changes to it during Emacs 29's dev cycle, but I'm not sure which one would have that effect. Anyway, with this definition: (defun pixel-width (string) (if (zerop (length string)) 0 ;; Keeping a work buffer around is more efficient than creating a ;; new temporary buffer. (with-current-buffer (get-buffer-create " *string-pixel-width*") ;; `display-line-numbers-mode' is enabled in internal buffers ;; that breaks width calculation, so need to disable (bug#59311) (when (bound-and-true-p display-line-numbers-mode) (display-line-numbers-mode -1)) (delete-region (point-min) (point-max)) (insert string) (save-window-excursion (set-window-buffer nil (current-buffer)) (car (window-text-pixel-size nil nil nil t)))))) In Emacs 29, (pixel-width "abc") returns 54 here (on a 4K screen). But no matter what I do, it returns 0 in my Emacs 28.2 (from official tarball). To get some more info: if I remove the 'car' call, the value that window-text-pixel-size returns is (54 . 36) in Emacs 29 and (0 . 108) in Emacs 28.2.