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.
Now the time for importing the kitty.config module has been halved, from
16ms from 32ms on my machine. Also, the new architecture will eventually
allow for auto generating a bunch of python-to-C boilerplate code.
Some legacy terminal applications get confused seeing CSI u escape
codes. Since it is relatively common to press ctrl or shift and
space/enter/tab/backspace, emit the same bytes as traditional terminals
do for these common keys.
Now such ligatures are detected based on glyph naming convention.
This removes the gap in the ligatures at cell boundaries. However, at
least in Fira Code the infinite length ligature glyphs define a negative
left side bearing. This means they overlap when drawn consecutively,
leading to unsightly bumps at the joins.
Fixes#2695
For some reason it puts empty glyphs after the ligature glyph rather than before it.
There is a possibility this fix might break something else, we will see.
Fixes#3313
