ensure a common cursor position after printing a sixel in direct mode

[db48x]

It looks like xterm leaves the cursor at the last line of the image, one past the last column, while Alacritty leaves it on the first column of the line after the image.

It sure would be nice if notcurses abstracted this difference away. :)

[db48x]

Or possibly xterm leaves the cursor at the first column of the last line of the image? Perhaps it depends on where the sixel cursor ends up…

And I have no idea what the VT340 did.

[dankamongmen]

and mlterm makes it visible, for unfathomable reasons! thanks for the heads-up, definitely a Notcurses job (if not a particularly exciting one).

[dankamongmen]

one thing i need go look at all subject terminals about is how they update the cursor (and for that matter draw the graphic) when in RTL orientation. IMHO, if you're going RTL, you ought draw your image RTL as well, and place the cursor to the left of it when done. i doubt this is done anywhere.

if you're using Qudum Mongγol bičig and writing top to bottom, i assume you're accustomed to nothing working, ever.

[dankamongmen]

just as a note to myself, this doesn't matter in rendered mode, since we always do a hard cursor move there.

you know, maybe we ought do the same thing in direct mode, which would allows us to remove the leaky abstraction plumbing C=1 through to kitty_blit(). we just have to be able to know where the cursor ought be. were we to do yet another terminal-specific grotesque hack here, it ought be a mere matter of moving the cursor back with alacritty.

this actually kinda sucks, though, because if alacritty is moving the cursor down below the graphic, they're also presumably scrolling if we blit to the last line. blargh.

the issue here might be more one of alacritty not honoring 8452:

Ps = 8 4 5 2 ⇒ Sixel scrolling leaves cursor to right of graphic.

yeah, i kinda think that alacritty is failing to honor 8452 here. i'll file a bug against them.

given that the sixel code still(!) has not been merged in alacritty, i don't see any need to put in code to differentiate and handle older versions of alacritty -- if we can get this fixed, it'll be present from day 1 of their sixel support. you agree with all this, @db48x?

[dankamongmen]

hrmmm, we get the same results in ncplayer -k between xterm and alacritty

[db48x]

That is an excellent point; I hadn’t considered that. I’ve just now tried implementing this in Alacritty, with some success:

Perhaps after a little 8–hour nap I will be able to figure out why it stayed on the correct line but reset to the first column even though I told it not to.

[db48x]

Nevermind:

[dankamongmen]

i intend to get to this soon, definitely in the 2.3.x cycle, but probably not within the next week. i'm considering it lower priority than some other things due to the existence of a workaround (unconditional postblit positioning of the cursor). if that's giving you any kind of problem, due perhaps to an inability to reliably determine the desired cursor position, please let me know and i'll bump up the priority.

[db48x]

I made a merge request for Alacritty, so hopefully there will be few special cases.

[dankamongmen]

awesome

[dankamongmen]

i just posted "why haven't they merged your good shit yet?" in the alacritty issue, because i'm a goddamned moron, though my question still stands.

this is currently breaking video playing with ncdirect_stream() on alacritty when the video does not stretch across the width of the screen, e.g. ncplayer -k -bpixel -snone ../data/fm6.wmv in alacritty.

[dankamongmen]

@db48x , just wanted to let you know that direct mode is likely to be weakly deprecated, in the sense that i'm not going to be putting effort into it going forward, and new code ought be written to use "cli mode". this latter is just the main Notcurses API together with some flags plus a scrolling standard plane. direct mode will continue to be supported through at least Notcurses IV.

bugfixes like this will still happen where necessary.

[dankamongmen]

i think commit 34869d3 might have just resolved this.

[dankamongmen]

i know that in growlight-readline in kitty, running the version command, we see the following:

[dankamongmen]

the behavior above no longer occurs in any emulator i can find to test with. i think we're good here now.