Re-enable cursor in signal handler

[hpjansson]

Brought up by @saitoha in #307.

If we disabled the cursor on startup (i.e. --polite off or auto), and the user issues a SIGINT (ctrl-c), we currently wait until chafa can handle the interrupt flag and reenable the cursor on exit. However, if it's stuck on CPU or I/O, this can take a while, and if the user gets impatient and hits ctrl-c again, the program will abort without reenabling the cursor.

Even if there's not a lot we can do in a signal handler, we can still do a write(). We could thus pregenerate the cleanup string to re-enable the cursor and possibly other settings and write it immediately when the signal arrives and avoid this annoyance.

[saitoha]

When canceling control sequences such as SIXEL, I recommend outputting the control character 0x18 (CAN) or 0x1A (SUB).
Although few terminals implement this behavior as described in the DEC manuals, these characters tell the terminal that a control sequence was aborted, preventing incomplete frames from being displayed -- at least on properly implemented terminals.
For terminals that don’t recognize CAN, it’s best to include a fallback ST sequence, and output them in the following order:
CAN (\x18) → ST (\x1b\x5c) → CSI ? 25 h.

[j4james]

Note that a SUB control is supposed to output an error glyph (typically a reverse question mark or "blotch") when it aborts a sequence, so it's not advisable if you want a clean break.

Also note that none of these controls will do anything to prevent incomplete frames from being displayed on a real terminal (or a serious emulator), because sixel images are displayed progressively, as the bytes are received. But there's probably no harm in sending CAN if you think it'll help on some modern terminals (assuming you do actually want to try and hide partial output).

[saitoha]

Also note that none of these controls will do anything to prevent incomplete frames from being displayed on a real terminal (or a serious emulator), because sixel images are displayed progressively, as the bytes are received.

You're absolutely right. I had long misunderstood that using CAN or SUB would cause each frame to be discarded as part of proper emulation behavior, but thinking it over again, I realize your explanation makes more sense. Simply outputting ST -> CSI ? 25 h might be sufficient.

[hpjansson]

Thanks, that's very useful - I'll add CAN and ST. I also think that the first time the user hits ctrl-c, it should install a 250-500ms timer in addition to the flag to give the terminal output a chance to finish cleanly (in the common case where it's not actually being slow), but come back and finish the job if it doesn't.

[hpjansson]

Ideally it'd be a fully async GMainLoop, but for that to happen, the image loaders must run in a separate process (we want this for security reasons too), and the Chafa rendering API must be cancelable (not sure if worth the effort).