mlterm bleedthrough of \eP0+r

[dankamongmen]

Run notcurses-input in mlterm. We see "input" of \eP0+r\. We don't see this in notcurses-info, so it's presumably a response to some query of ours.

[dankamongmen]

this would be a "device control string" ESC P: Device Control String ( DCS is 0x90)

[dankamongmen]

wait, it looks like we already ought be recognizing this as a negative XTGETTCAP?

    { "P0+r\\S", NULL, },    // negative XTGETTCAP  

[dankamongmen]

process_melange:2227:input 19 (0)/4076 [0x1b] ( )
process_escape:2056:initialized automaton to 1
process_escape:2068:walk result on 80 (P): 0 386
process_escape:2068:walk result on 48 (0): 0 393
process_escape:2068:walk result on 43 (+): 0 394
process_escape:2068:walk result on 114 (r): 0 395
process_escape:2056:initialized automaton to 1
process_melange:2227:input 20 (1)/4075 [0x50] (P)
process_melange:2227:input 21 (1)/4074 [0x30] (0)
process_melange:2227:input 22 (1)/4073 [0x2b] (+)
process_melange:2227:input 23 (1)/4072 [0x72] (r)
process_melange:2227:input 24 (1)/4071 [0x1b] ( )
process_escape:2068:walk result on 92 (\): 1 0
process_melange:2227:input 26 (0)/4069 [0x1b] ( )
process_escape:2056:initialized automaton to 1

[dankamongmen]

DCS 0 + r Pt ST for invalid requests. The strings are encoded in hexadecimal (2 digits per character).

it looks like mlterm simply isn't terminating with a ST?

[dankamongmen]

so we either strengthen our automaton so that we can list both signatures, or we get mlterm fixed upstream...

[dankamongmen]

[schwarzgerat](127) $ echo -e '\eP+q5443\e\\'

[schwarzgerat](0) $ :0+r^[\

[dankamongmen]

hrmm at least current mlterm does seem to be writing it correctly, then?

vt_write_to_pty(vt_parser->pty, "\x1bP0+r\x1b\\", 7);

[dankamongmen]

if i reduce the automaton match to P0+\\S from P0+r\\S, it works here. i think i'll take that with a smile.