GNU bug report logs - #63544
28.3; extra width not renderes correctly in TUI when making a character wider

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63544 in the body.
You can then email your comments to 63544 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Adam Ibrahim <ibrahimadam193 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.3; extra width not renderes correctly in TUI when making a
 character wider
Date: Tue, 16 May 2023 15:34:38 -0400

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

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.

consistently works with:

- Termux, iosevka
- xfce4-terminal, iosevka and source code pro
- Kitty, iosevka

[Message part 2 (text/html, inline)]

Message #8 received at 63544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adam Ibrahim <ibrahimadam193 <at> gmail.com>
Cc: 63544 <at> debbugs.gnu.org
Subject: Re: 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

tags 63544 notabug
thanks

> From: Adam Ibrahim <ibrahimadam193 <at> gmail.com>
> 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.

Message #15 received at 63544-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adam Ibrahim <ibrahimadam193 <at> gmail.com>, 63544-done <at> debbugs.gnu.org
Subject: Re: bug#63544: 28.3; extra width not renderes correctly in TUI when
 making a character wider
Date: Sun, 3 Sep 2023 03:35:24 -0700

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

> tags 63544 notabug
> thanks
[...]
> 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.

I'm therefore closing this bug report.

Previous Next

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