ncvisuals no longer correctly positioned in xterm <357

[joseluis]

all ncvisuals are rendered at 0,0 when using xterm

[dankamongmen]

you probably just updated from 368 to 369, with its inverted DECSDM. what version of xterm, what version of notcurses?

[dankamongmen]

seeing xterm 369 work just fine with

working on xterm 369 with notcurses 2.4.5

[dankamongmen]

see #1782

[joseluis]

OK!

I'm using the xterm packaged from my distro, version 353.
And the latest notcurses from master.

[dankamongmen]

I'm using the xterm packaged from my distro, version 353. And the latest notcurses from master.

ahhh, ok, i might have fucked up the xterm version check then; i don't think i tested with a sub-369. let's see.

[dankamongmen]

i sure did, augh, good find!

[dankamongmen]

hopefully what i just pushed ought fix it, ugh

[joseluis]

Mmmm no, it still suffers from the same problem.

For example, the orca in notcurses-demo remains at the top left corner, as well as any other positioned ncvisual.

BTW this is my package: https://packages.ubuntu.com/focal/xterm

[dankamongmen]

can you give me a quick screencap of notcurses-info? stderr logs from notcurses-info -v might also prove very useful. thanks!

[joseluis]

sure

info-stderr.txt
info-stdout.txt

[dankamongmen]

hrmmm so it's not recognizing XTerm here. note how in mine, on the top line, it says "on XTerm 369". yours is just reflecting your $TERM. is this possibly being run in screen/tmux?

[dankamongmen]

so since it can't recognize XTerm (because it's not getting an XTVERSION response), it can't compare versions, and that's why we're getting the failure. the real problem here is that we're not getting an XTVERSION response. why? hrmmmm

[dankamongmen]

unsure when xtversion went into xterm, but DA2 has had a version number since at least 1999

Patch #95 - 1999/4/5 - XFree86 3.9Ph use the patch number (e.g., 95) in the secondary DA response, providing user applications a means of determining the version of xterm for feature comparison (request by Bram Moolenaar).

[joseluis]

is this possibly being run in screen/tmux?

no, it's standalone, run with xterm -tn vte340

[joseluis]

OK, two things:

1. regarding xterm detection, it turns out that when I open the xterm window from inside a tmux session... it doesn't show the xterm name, but if I open it from the menu, it does show the right name xterm-256color. That's unexpected...
2. either way it doesn't change the behaviour of the ncvisuals. In both instances they remain at the top left corner.

[dankamongmen]

i'm now reproducing your failure using the ubuntu focal xterm-353 package.

[dankamongmen]

this xterm definitely does not respond to XTVERSION.

[dankamongmen]

with the change i just committed, we identify XTerm, though not yet get its version, and i don't see any sixels at all.

probably not gonna work on this anymore tonight, but ought get it pretty quickly tomorrow omrning.

[dankamongmen]

we now extract these older versions from DA2

[dankamongmen]

so i can't get any sixels to display anywhere using this older xterm =[. i'm now at least extracting the version properly etc. @joseluis i assume there has been no change in behavior?

[dankamongmen]

according to the XTerm changelog, sixel support has only been present by default since XTerm 359, released 2020-08-17:

Patch #359 - 2020/08/17 .... enable SIXEL feature by default.

[dankamongmen]

and when i do a primary device attributes request, we do not see the '4' indicating sixel support:

[schwarzgerat](0) $ 64;1;2;6;9;15;16;17;18;21;22;28c

so how are you seeing sixels with this build at all?

[dankamongmen]

i've cherry-picked 69db355 and 0450951 into master.

[dankamongmen]

sure

info-stderr.txt info-stdout.txt

i'm not seeing a sixel here anywhere....?

[dankamongmen]

well, i'm extracting XTerm 353 out correctly now, but this ubuntu package definitely does not have sixel support. so i'm very confused as to how you could have been seeing sixels in the upper left.

however, i notice something very interesting....it's answering XTSMGRAPHICS as if it did have support. but the DA1 response clearly indicates no support. i don't believe i've ever seen this happen.

[dankamongmen]

[schwarzgerat](0) $ echo -e '\e[c\e[?2;1;1S'
[schwarzgerat](0) $ 64;1;2;6;9;15;16;17;18;21;22;28c2;0;880;552S

[joseluis]

oh man, don't worry too much about this ass old version of xterm that in two years will be forgotten.

I'm about 1000x times more excited about #2258. I'll close this in a moment if that will help you focus on that one!

[dankamongmen]

i mean, there's no cost to leaving it open... but I do now have us identifying the version of pre-XTVERSION XTerm, which is a Good Thing, and we've opened the discussion on #2257, which is a Necessary if Unpleasant Thing, and we fixed a real bug in DECSDM inversion detection in XTerm, which is a Very Good Thing, and we're working as exepected when I test under XTerm 353 as packaged in Ubuntu Focal, which is a Reassuring Thing Though Also a Confusing Thing Given Your Claims, so sure i'm happy to close this up.