Now it is allocated on demand. This prevents it from blowing up
to READ_BUF_SZ * 2 (2MB) if a small pending update is followed by a
large non pending section in the read buffer, which is commonly
triggered for instance by the transfer kitten which uses pending updates
for its screen drawing mixed with non-pending data transmission.
This is a slight performance penalty since there is a branch when
writing every char to the pending buffer, but the branch will be almost
always one sided so should be well predicted.
In any case, filling the pending buffer is not a performance bottleneck,
compared to actually dispatching parsed escape codes.
Now a stack of depth 1 is used to save/restore private mode values. And
saving/restoring individual modes is supported. This latter is used by
midnight commander.
A better solution from an ecosystem perspective is to just work with the
original protocol. I have modified kitty's escape parser to special case
OSC 52 handling without changing its max escape code size.
Basically, it works by splitting up OSC 52 escape codes longer than the
max size into a series of partial OSC 52 escape codes. These get
dispatched to the UI layer where it accumulates them upto the 8MB limit
and then sends to clipboard when the partial sequence ends.
See https://github.com/ranger/ranger/issues/1861
Should get much closer semantics in the two cases and its nice not to
have an extra mini VT parser for pending mode. There is a performance
hit in pending mode, since now the pending mode bytes are round tripped
via utf-8 decoding/encoding, but its worth it for the code
simplification.
Because, why the hell not, it's not like I have an actual life.
More seriously, terminal-wg (aka Bikeshedder's Anonymous) is
pushing for it so it's likely at least one poor application writer
will fall for their propaganda.
Treat the XTerm specific modifyOtherKeys escape codes as putting the
disambiguate mode on/off the stack. The escape code causes XTerm to use
a (broken, naturally) variant of CSI u encoding for many keys, so we
treat it as going into the disambiguate mode.
Up to now this poorly designed and completely unnecessary escape code
was relegated to only GNOME, however, off late Apple has started using
it as well, so silently ignore it, instead of spamming error messages
for it.
Now the full list of secondary characters (intermediate bytes) is used from ECMA 48
Also the codes that accept only one parameter now report errors when
multiple parameters are passed.
