bug#63544: 28.3; extra width not renderes correctly in TUI when making a character wider

bug#63544: 28.3; extra width not renderes correctly in TUI when making a character wider

[Adam Ibrahim]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 707 bytes --]

bug#63544: 28.3; extra width not renderes correctly in TUI when making a character wider

[Eli Zaretskii]

tags 63544 notabug
thanks

> From: Adam Ibrahim <ibrahimadam193@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.

bug#63544: 28.3; extra width not renderes correctly in TUI when making a character wider

[Stefan Kangas]

Eli Zaretskii <eliz@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.