current head of master is misplacing closing banner in notcurses-info on apple

[dankamongmen]

I've only been able to reproduce this on macOS, but it seems unlikely that it's truly related to that. This does not happen with the 2.3.13 release, so it must be very recent. Running at the bottom doesn't see our stderr scroll out, but intstead it is reproduced atop us, see below:

[dankamongmen]

confirmed that 9fcbf00 (v2.3.13) does not show this behavior. gonna bisect now.

[dankamongmen]

ee2fcb4 still works. there is then a great span of uncompilable checkins because i have poor impulse control. it's broken by at least 5cb1275.

[dankamongmen]

broken by at least bbaa3f4.

[dankamongmen]

ok, a different strategy. if you capture stdout, we look fine on both linux and macOS (we just scroll up for stderr, as expected). then try catting the output you just captured. on linux, the cursor ends up below the output. on macOS, the cursor ends up in the middle of the output.

and indeed, looking at it, on linux we have:

[55;55H^[_Ga=p,i=11935608,p=1,q=2,C=1^[\^[[69;47H ^[[55G ^[[63G ^[[66G ^[[?1002;1006l^

whereas on macOS we have:

^[[55;55H^[_Ga=p,i=7207457,p=1,q=2,C=1^[\^[[?1002;1006l^

so we've got ^[[69;47H ^[[55G ^[[63G ^[[66G on linux and not macOS, and that is indeed what fixes things up on linux.

[dankamongmen]

swapping out src/info/main.c doesn't fix anything, so this is down in the render logic, curses.

[dankamongmen]

so either way, this is emerging from the second glyph pass. we ought be getting our final placement due to goto_location() through the end of rendering, though, unilaterally.

[dankamongmen]

ahh so this only is specific to macOS because only macOS is missing all the Unicode 13 emoji at the bottom.

[dankamongmen]

going to 54/54 from 68/78
going to 70/0 from 54/54
FINAL GOTO: 70
going to 70/0 from 70/0

[dankamongmen]

ok, i've confirmed that we think we're at line 70 upon hitting notcurses_stop(), which of course we aren't.

[dankamongmen]

so we're convincing ourselves during ncpile_rasterize() that we're down on line 70 (we enter thinking we're on 69, which i think is correct; either way, we move wildly elsewhere in the course of rasterizing).

[dankamongmen]

going to 68/76 from 68/76 hard: 0
going to 68/77 from 68/77 hard: 0
going to 53/54 from 68/78 hard: 0
going to 70/0 from 53/54 hard: 1
----------------- END RENDER 70/0
x/y: 0/70 70
x/y: 0/70 TARG: 70 LFDIM: 70
going to 70/0 from 70/0 hard: 0

so on the elided move we have hard: 1. could that be it?

[dankamongmen]

ohhhhhh yeah i think i maybe see the problem

[dankamongmen]

hrmmm nope we emit the expected cup:

elide forever <3
going to 68/76 from 68/76 hard: 0
elide forever <3
going to 68/77 from 68/77 hard: 0
elide forever <3
going to 53/54 from 68/78 hard: 0
CUP
going to 70/0 from 53/54 hard: 1
CUP

[dankamongmen]

awwww fuck me in the ass

[dankamongmen]

CUP
THIS IS A BULLSHIT WRITE
going to 70/0 from 53/54 hard: 1
CUP

arrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

[dankamongmen]

ok, yep, this bug was straight-up introduced during the move from memstream to fbuf necessary for windows. le sigh. i suppose if this is the only evening wasted, we got off easy.

[dankamongmen]

alright, fixed, though we've reintroduced the relatively benign #2021, lol