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#63544: 28.3; extra width not renderes correctly in TUI when making a character wider Date: Wed, 17 May 2023 16:25:17 +0300 Message-ID: <83ednfxf7m.fsf@gnu.org> References: 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="24655"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63544@debbugs.gnu.org To: Adam Ibrahim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 17 15:26:37 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 1pzHAq-0006DH-SQ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 May 2023 15:26:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pzHAh-0006nt-Ml; Wed, 17 May 2023 09:26:27 -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 1pzHAT-0006mu-K4 for bug-gnu-emacs@gnu.org; Wed, 17 May 2023 09:26:18 -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 1pzHAI-0002pH-6t for bug-gnu-emacs@gnu.org; Wed, 17 May 2023 09:26:11 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pzHAH-0006Wj-SZ for bug-gnu-emacs@gnu.org; Wed, 17 May 2023 09:26: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: Wed, 17 May 2023 13:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63544 X-GNU-PR-Package: emacs Original-Received: via spool by 63544-submit@debbugs.gnu.org id=B63544.168432992325028 (code B ref 63544); Wed, 17 May 2023 13:26:01 +0000 Original-Received: (at 63544) by debbugs.gnu.org; 17 May 2023 13:25:23 +0000 Original-Received: from localhost ([127.0.0.1]:49281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pzH9e-0006Vb-W5 for submit@debbugs.gnu.org; Wed, 17 May 2023 09:25:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pzH9d-0006VK-6S; Wed, 17 May 2023 09:25:21 -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 1pzH9X-0002Zw-Su; Wed, 17 May 2023 09:25:15 -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=vqO75dRvLPueylOw3rnc7Tf7JLiTIzRv6PPxFm1VuwY=; b=TWZcXrFSJbVDo7CBJ8RO eftUQwynFw941mnYggzH0lZDeraPopsNyvnmPAyZcHxVqLT9yJQDtmYeBg+TQiGtxJbG+NCp1qwMf lPPM9Gghagsnktxk8rr6OgOu7FZof/qajArp5rflAnDX6DxnOL3tpHtN5HtoHjgI8t7NupPogZ/wv DMxp1i+xm2hfOyEF2IAEKabWvLQxEhyA5Ggd0cebabhNQFpcqRkMMbgBXAqvvKrMrIWoM4DjXrO0j 62wsyUGLLl/4ysj4knWY1y9CtIl/WnpXdCudnX60iSg+FuDFLdod+filJ6B1dRLsAcwhbqqb5lI/q ENYIDkrVFrlAKQ==; 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 1pzH9Q-0006mN-CO; Wed, 17 May 2023 09:25:15 -0400 In-Reply-To: (message from Adam Ibrahim on Tue, 16 May 2023 15:34:38 -0400) 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:261848 Archived-At: tags 63544 notabug thanks > From: Adam Ibrahim > Date: Tue, 16 May 2023 15:34:38 -0400 > > When I make a character wider by changing the char width table, it isn't > sometimes with shows and sometimes it doesn't. > > 1. Start up emacs with this command. > > emacs -Q --eval '(progn (set-char-table-range char-width-table #x221e 2) (set-char-table-range > char-width-table #x2014 2))' > > 2. Type "—a" into the scratch buffer. The em dash should be correctly rendered two cells wide, and the > a shouldn't overlap with the em dash. > 3. `M-x redraw-screen`. The em dash should now overlap the a. (I guess you mean "M-x redraw-display". There's no redraw-screen command in Emacs.) I'm guessing you did the above in order to cause the em-dash character display as two character cells instead of just one. But that will only work if, when the em-dash character is written to the terminal, its glyph indeed takes two character cells, and the terminal tells the driver that the "virtual write cursor" was moved by two character cells. Emacs expects double-width characters to produce that effect, and evidently in your case this character doesn't. The upshot is that we cannot support artificially "widening" characters which don't behave like double-width characters from the POV of the terminal emulator. Just using a font where the character's glyph is wide is not enough; you need the terminal emulator to understand that this is the case with these characters, and behave accordingly. The above "sometimes works" because Emacs doesn't always write the entire screen line of the characters. It tries very hard to minimize the writes to the glass. So when you type the initial '—' character, Emacs writes only it, and then moves the display cursor to where it thinks it should be -- which is column 2 (zero-based). Then, when you type 'a', Emacs inserts just the glyph for 'a', it doesn't redraw the first '—' character. By contrast, when you invoke redraw-display, Emacs redraws the entire line, expecting the 'a' character to be written by the terminal emulator starting at column 2, not column 1. It expects the terminal emulator to make sure this is what happens when Emacs writes the string "—a" to the terminal. But in your case, it doesn't: the 'a' character starts at column 1, so it overlaps with '—'. IOW, Emacs assumes that writing a single character '—' occupies 2 columns no matter whether there are or aren't characters after '—'. And that requires the terminal emulator to play along, when you use Iosevka (and other similar fonts). This is not a bug. I don't see how Emacs could do anything here to fix the terminal emulator, without causing serious degradation in redisplay performance. Sorry.