Re: [PATCH] [libtermdraw] Ensure that t.x tracks character widths

["S. Gilles" <sgilles@xxxxxxxxxxxx>]

On 2017-10-30T01:15:42-0700, Ori Bernstein wrote:
> Applied, although I think we're still not unicode-ly correct. Right now,
> the code seems to largely make the assumption that each codepoint takes
> at least one cell.
>
> So, it seems when we do a `put`, we'll clobber combining characters
> with zero width. For example, taking the zalgo text:
> 
> 	t̸̹͒̿̉̓ͫ͗̿e̻͍͇̤ͯͪ̔̑̿̈sͦ͑ͫ͒̀t̞̊͌
> 
> will format the string correctly into a buffer, and then walk through char
> by char doing termdraw.putc to place the characters.
> 
> Termdraw.putc will place down the `t`, and advance by 1 character, then put
> down the the combining mark, and advance by 0 characters, overwriting.  And
> then overwrite with the next combining mark, and so on, until it's done with
> all the zero width characters. Then it'll put down the `e`, which will clear
> out the last combining mark, and repeat util it's done with the string.

Hm. Perhaps it's my choice of terminal or fonts, but I don't see
zalgo text even in ncurses or cat. That will make it difficult to
verify if another method works better.

Going to the other end of the scale, if we have "foobar" queued up,
and we overwrite the "f" with a double-wide "ｆ", that will clobber
the first "o" - even though the chr remains, flush will step over
it.

> I'm not sure what the nicest design to fix this would be, since being
> able to seek around and plonk down a character at an (x,y) coordinate
> still should be efficient, and it feels wrong to store arbitrary strings
> for each cell. Might be the only way, though.

Agreed on the (x,y) addressing, I don't think it would be desirable
to do a replacement that doesn't allow it.

It seems that the only thing requiring arbitrary strings is long
stretches of zero-width characters, though. Perhaps it would be
possible to keep the characters with >0 width in the main array,
then store the arbitrary strings of 0-width joiners in an auxiliary
array. Or perhaps that's over-complicating it.

> On Mon, 30 Oct 2017 00:36:19 -0400, "S. Gilles" <sgilles@xxxxxxxxxxxx> wrote:
> 
> > +			var cn = std.cellwidth(t.buf[i].chr)
> > +			if cn > 1
> > +				x += cn - 1
> > +			;;
> 
> Minor nit: I tend to declare vars at the start of the function. Changed that
> over here. Also added a comment, since adjusting the iteration var in two
> places is odd enough that it could stand a bit of attention.

Fair enough - that's actually something I tend to do as well (another
C habit), but I had been actively trying to avoid it after hearing
people say it was confusing. I don't have strong opinions on the
matter myself, so I'll go for project consistency in the future.

> [snip]

-- 
S. Gilles