globally, the first and third patch should be squashed together (as first patch) second patch is pure dead code, so it should be squashed with fourth IMO the global design of the parser has to be be reviewed: * it mostly assumes that the whole sequence will be passed in the buffer; this is not always the case (esp if emittter has unbuffered output) * so it should be ready to handle an incomplete sequence, stash the incomplete sequence somewhere, and try to get a complete sequence when new data is available * error handling: the strategy when dealing with an "invalid" sequence shall be defined; note that since you can have several emitters, pushing characters one by one, that you must be prepare for incorrect sequence so basically, the parser shall look like: * if valid complete sequence, remove it from input buffer, and process it * if valid incomplete sequence, stash incomplete sequence and retry to complete incomplete seq with new incoming data * if invalid sequence.... not 100% clear to me what would be the best behavior... this MR drops the \\x1b and moves on to the next characters... invalid here covers both syntactically incorrect char stream and recognized but unsupported esc sequence... maybe we would need to separate the two (in the MR for an unsupported sequence, current code drop the \\1xb and emits the rest of the string... either we should drop the whole sequence, or keep it untouched - on one hand the unix console could make use of it, but on the other hand that means two different behavior between the two backends... which we currently have) I leave that open for now, feedback welcome :-) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9973#note_133064