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: Tue, 11 Jul 2023 14:48:16 +0300 Message-ID: <83y1jm7jpb.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> 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="16853"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64420@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 11 13:49: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 1qJBrs-00046b-UX for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Jul 2023 13:49:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJBrd-000158-Hl; Tue, 11 Jul 2023 07:49:05 -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 1qJBra-00014m-7U for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2023 07:49: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 1qJBrZ-0003ey-Us for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2023 07:49:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qJBrZ-0008BI-Q5 for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2023 07:49: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: Tue, 11 Jul 2023 11:49: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.168907609231271 (code B ref 64420); Tue, 11 Jul 2023 11:49:01 +0000 Original-Received: (at 64420) by debbugs.gnu.org; 11 Jul 2023 11:48:12 +0000 Original-Received: from localhost ([127.0.0.1]:49863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJBql-00088H-S8 for submit@debbugs.gnu.org; Tue, 11 Jul 2023 07:48:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:32946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJBqk-00087U-8R for 64420@debbugs.gnu.org; Tue, 11 Jul 2023 07:48:10 -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 1qJBqe-0003QY-BP; Tue, 11 Jul 2023 07:48:05 -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=GeqvEhLk6ocN5awhLNO4cKKeOKjSYuqWIYidUtUezLU=; b=YHntpMxTpWHUSr8lhg2A sWjbt8o81wYkh7NaRZgGLEULxsKUO6LyEu3UwVL0bFMbRtd8reMCd291rIEJdsQ98TowrB2KcMu8n 03GNVKpgQAnSQRxQeSh+W3z/ryhD2NugY+6f/rfz5PF+5zGn40MS3b3F2rzJPC8CrlpMJdJlnWoHx jGHz9CE3u6Z0F6xd3QWxzFwGIAh/rc67XjsjF1cH1qLvHBjm15nJyWn3GZ863q3c4RxHYSI1g4VhY 0VhfDxchw6leewrb2x71MJMLOf/w+9T2g0ci1F0r05v8x4xdKnI22p2BGjKgA7Uq3BTXl1R5ujOIl smGu9hyECqy6GQ==; 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 1qJBqd-0005Uy-Pt; Tue, 11 Jul 2023 07:48:04 -0400 In-Reply-To: <0c50468b-dec5-c269-7d71-d255ed6d76ae@gutov.dev> (message from Dmitry Gutov on Tue, 11 Jul 2023 05:23:03 +0300) 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:264923 Archived-At: > Date: Tue, 11 Jul 2023 05:23:03 +0300 > Cc: 64420@debbugs.gnu.org > From: Dmitry Gutov > > 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?