xtsmgraphics pubsub

[dankamongmen]

for your august consideration...

Abstract

When the pixel geometry of the terminal changes, it is possible that a XTSMGRAPHICS maximum pixel size reported earlier is invalidated. A client interested in this value must then requery. It would be nice if the terminal could just send me the new XTSMGRAPHICS result, either based on my initial XTSMGRAPHICS request or, if it is undesirable to introduce new behavior in response to existing sequences, via some "subscribe" sequence (perhaps a new action in XTSMGRAPHICS, "get and subscribe").

Ideally this would arrive before the next time I wrote, but that's obviously racy all the way down. No worries there.

Motivation

Whenever a pixel geometry change is effected, a client program's information regarding the maximum sixel size might be invalidated. If an existing Sixel is larger than this size, it is presumably damaged, and definitely can't be drawn again using the original draw size. It's thus a practical necessity to query XTSMGRAPHICS again after any such change, incurring a RTT latency, followed by Sixel reencoding latency before it can write. If geometry changes are detected only at draw time (reasonable IMHO given the lossy nature of POSIX signals), this is a worst case, entirely unhidden latency.

In general, I'd like a client program to be notified of settings changes, ideally in a fine-grained manner. This issue further intends to explore that space a little.

Specification

IMHO, the cleanest solution is to add to

Pa = 1 ⇒ read attribute. Pa = 2 ⇒ reset to default. Pa = 3 ⇒ set to value in Pv. Pa = 4 ⇒ read the maximum allowed value.

Pa = 5, for read + subscribe to value changes. when this is supplied, the terminal will communicate in a timely manner any changes to XTSMGRAPHICS. no timing information relating this control sequence, any SIGWINCH signal (if one exists), and the actual effect is guaranteed.

this is stupid and you're also stupid for suggesting it

• It can be argued that this mechanism is theoretically no more reliable than SIGWINCH, which I'll grudgingly admit. With that said, a pipe holds a lot more than a word of signal-pending bits.
• The flipside of the above: this message could be blocked by a bunch of existing input in your pipe, whereas a signal has no queue. Sure, but if you need read the XTSMGRAPHICS reply anyway, that's going to get blocked by the same assumed crap. It'll just arrive 1 RTT later.
• It requires handling some async message: you have to do the same thing to handle the query reply.
• We must act as if this is the time of Charlemagne, and refrain from extending DEC's holy Writ. I reply with mokusatsu.

So long as we assume the client is always going to query XTSMGRAPHICS upon a pixel geometry change, this mechanism seems to me strictly superior.

[christianparpart]

@dankamongmen you know I'm legally blind and my screen reader has lunch-break as ordered by the union labor, right? :-D (okay, too much bling bling).

Many thanks for that, I'll actually however take some time to read through all-of-it without accidentally losing some bits. I'll respond before August though (did you know that I like to release major releases on Birthdays? Hmm, August, hmm...) :-D

[dankamongmen]

apologies! this is in no way a high-value nor high-importance item.

the adjective sense of august:

  august
      adj 1: of or befitting a lord; "heir to a lordly fortune"; "of
             august lineage" [syn: {august}, {grand}, {lordly}]
      2: profoundly honored; "revered holy men" [syn: {august},
         {revered}, {venerable}]
      n 1: the month following July and preceding September [syn:
           {August}, {Aug}]

[christianparpart]

I will serve you with pleasure.

[dankamongmen]

i'd read about your screenreader, but hadn't really internalized it. i will aim to accommodate this in further communication!

[ghost]

mintty has a similar option for this, they call it "font change reporting": https://github.com/mintty/mintty/wiki/CtrlSeqs#font-change-reporting . Not sure if it would trigger only on a size change with the same font though.

[dankamongmen]

mintty has a similar option for this, they call it "font change reporting": https://github.com/mintty/mintty/wiki/CtrlSeqs#font-change-reporting . Not sure if it would trigger only on a size change with the same font though.

awesome @klamonte , i had no idea. @mintty, care to provide an answer? if it doesn't report on a size change, could that be added to this functionality?

[christianparpart]

I like. I am also all in for converging to something so we don't have a dozen of sequences for the same thing. @dankamongmen - I first have to please notcurses-info/demo a bit more as I keep finding interesting bugs that I wanna fix before moving on to the fun part.

Marry Christmas to all ;-)

[mintty]

Font change notification is intended to notify possibly different sets of supported character (glyphs included in the respective font), which can be enquired with another mintty sequence. This way, e.g. text editors can adjust characters used for menu borders or line end indications to the available glyph set. It's not a use case to combine this with window size change. Window size change is notified via ioctl since mintty 3.5.1, following xterm 368, and should result in a SIGWINCH to the application (unless disabled). Mintty does not support XTSMGRAPHICS as its Sixel handling does not apply any such limits.