Weird glyph in upper left corner of uniblock demo when fade is removed

[dankamongmen]

We've run the 'uniblock' demo both with and without the fadein -- I can never decide which way I like it. For a while during 1.0.0 development, there was a weird glyph persistent through each block in the 0,0 cell of the uniblock plane. When I added the fade back in, it went away, but I didn't put the two together. I just removed the fade to investigate something, and it popped back up.

Figure this out irrespective of the fade.

[dankamongmen]

it looks like this only happens in VTE-based terminals, or at least does not on either kitty or alacritty.

[dankamongmen]

OK, that's \u0600 ARABIC NUMBER SIGN. it's a subtending mark, meaning it applies to a range of prior characters. Applying it to a box character is apparently no good:

[schwarzgerat](0) $ echo -e '\u0041\u0600'
A؀
[schwarzgerat](0) $ 

this shows up as a nasty glyph in xfce4-terminal

[dankamongmen]

We're not going to solve this anytime soon. The more worrying thing IMHO is that this glyph persists through several blocks, which it shouldn't be doing at all. That's crossing ncplane lifetimes.

[dankamongmen]

It persists even through notcurses_refresh()...that just writes the (minimized) rasterization buffer. So it's presumably skipping over the (thought undamaged) cell. That's why it does finally go away when we write a different pattern through.

• Hypothesis: this will go away if we start writing a random char between the glyphs in uniblock.
• Hypothesis: this will not go away just by increasing margin (i.e. the idea above that "applying it to a box character is apparently no good" is nonsense, or at least not the whole problem).

Second hypothesis was proven, first was disproven. I noticed something new: the U+0600 only occupies a single column, so far as I can tell, but you move through it with two keystrokes:

so....what the fuck's up with that

[dankamongmen]

fucking U+0600, you have vexed me for the last time. my fellow Americans, I'm pleased to tell you today that I've signed legislation that will outlaw U+0600 forever. we begin bombing in five minutes.

[dankamongmen]

new hypothesis:

• if i print a random character BEFORE this glyph (requiring margin), it will go away

testing...

[dankamongmen]

Yep, that did it 🗡️ :D

[dankamongmen]

So what does that mean?

• definitely notcurses_refresh() is not writing to that particular coordinate. which makes sense--it just thinks the same ol' vertical bar has been there

• and the vertical bar is there, because this is a combining character. it doesn't blow it away. but we never rerender the bar, because it's never damaged, so far as we know. even notcurses_refresh() doesn't, because it uses the post-rasteriation, optimized buffer. that's a bug, and would resolve this if reinserted the trial notcurses_refresh() i put in (and removed) earlier. Weird glyph in upper left corner of uniblock demo when fade is removed #259 has been created for this.

• I think the sliest way to get this fixed now is to slightly change the color of the bounding box with each iteration, heh. try this, and if it works, call it a day.

[dankamongmen]

That does indeed solve the one persistent upper left glitch. Others remain, but get blown away pretty quickly. I'm almost satisfied, but while we're on a roll, let's get it all.

Furthermore, I'm wondering if this doesn't really point at a flaw in rasterization. If we inserted a RTL corrector following any RTL EGC, would that not work? I tested with this before, but it was an RTL at the end of the 2xwchar_t block, which would break in this case...yes hrmmmmmm testing now...

[dankamongmen]

Yep, that pretty much gets it :D :D. That's a looooooooooooooooooooontime bug getting put to bed. We've been afflicted by this since the very earliest days.