Hello Ingo,
Ingo Schwarze <schwa...@usta.de> wrote:
|For example, colrm(1).
|4. The backspace character (U+0008) backs up by one display position
| rather than by one character. That causes miscounting when
| backspace follows a zero-width or double-width character.
this however is unfortunately common behaviour for terminals, too.
I explicitly misused this misfeature in my N(ail)C(ommand)L(ine
editor) commented as
* We do not handle character widths because the terminal must deal with that
* anyway on the one hand, and also wcwidth(3) doesn't support zero-width
* characters by definition on the other. We're addicted.
yet noone ever cared. I.e., you see the cursor advancing by two
spaces when a double-width glyph is inserted (e.g., xterm, nsterm)
but backspace and cub1/le will loose that knowledge! Especially
mysterious when then deleting at that position since it'll remove
the double-width character and place a space before the cursor!
For v14.9 of my thing i'm in the process of warping "NCL" to a new
"NLE", the commit message of which will say
Use termcap.c abstraction for movement and other such terminal
capability related operations instead of unrolling anything
ourselfs.
As a part of this, honour wcwidth(3): i will never understand why
terminals support double-width character insertion and move the
cursor accordingly even in non-canonical mode, but fail to deal
with that with successive cursor movements or \b. But it is like
that so NLE has to deal with it. Finally do.
I.e., BS==wcwidth(3)*BS/cub1/le for NLE. But what i'm trying to
say is that it seems that for plain \b the ship has sailed a long
time ago.
--steffen
