[RFC] Multiple cursors

[kovidgoyal]

Hi all,

I have just implemented support for multiple cursors in kitty using a new escape code protocol. Multiple cursors are used in many editor programs to allow the user to make the same change at multiple points in the file. Currently these are often implemented using a hack involving a Unicode solid block character or similar. I felt it would be nice to let TUI editors display native correctly rendered multiple cursors.

To try it out install a nightly build or build kitty from source. Then, you can show multiple cursors with:

# Show cursors of the same shape as the main cursor at y=4, x=5
printf "\e[>29;2:4:5 q"
# Show more cursors on the seventh line, of various shapes, the underline shape is shown twice
printf "\e[>1;2:7:1 q\e[>2;2:7:3 q\e[>3;2:7:5;2:7:7 q"
# Clear the cursors
printf "\e[>0:4 q"

The specification of the protocol and description of its semantics is in
multiple-cursors-protocol.rst

If anyone knows of any conflicts with existing usage of the escape code (which is based on the existing DECSCUSR escape code, with the addition of > do let me know, I can change it easily, if needed.

Also if people looking to implement it have any concerns on its semantics or design, now is the time to suggest changes.

Thanks.

Pinging a few people that might be interested, apologies for the noise:
@rockorager @neurocyte @dankamongmen @justinmk @the-mikedavis @mawww

[neurocyte]

Minor typo (screne) on line 167 of the spec.

[neurocyte]

As I understand it, the spec says all cursors are always the same color.

Many editors (including Flow Control) have the concept of a "primary" cursor. This is often accentuated by displaying the primary cursor in a slightly different color to the secondary cursors.

[kovidgoyal]

Yes, storing per cursor colors is a large performance cost (order of magnitude) it means storing 32 bits per extra cursor instead of the current 3 bits. Primary cursor can be distinguished from other cursors by shape only currently.

[kovidgoyal]

What could be done is storing a single color that is set for all extra cursor but not the main cursor. So, the main cursor could be color X and the extra cursors could all be color Y.

[neurocyte]

Also, how do multiple cursors interact with cursor movement animation like cursor trails? How does the editor maintain cursor identity to make aninimations apply across remove/place operations?

[neurocyte]

What could be done is storing a single color that is set for all extra cursor but not the main cursor. So, the main cursor could be color X and the extra cursors could all be color Y.

This would be enough for most cases I think.

[kovidgoyal]

Cursor blink animations apply to all cursor the same way. Trail is only for the main cursor (that incidentally can be another way the main cursor stands out from extra cursors). IMO it doesnt make sense to have trails for every cursor, it would look fairly messy and also the point of trails is to allow the eye to follow cursor movement, the human eye cant really follow multiple bits of movement simultaneously.

[neurocyte]

Cursor blink animations apply to all cursor the same way.

I might be desirable to have only the primary cursor blink, also to reduce noise. Could that be an extra attribute for all secondary cursors like the color?

[kovidgoyal]

There is no technical reason it cant (it's one extra bit) however, I dont think its a good idea. The point of multiple cursors is to make it very clear to the user what the edit locations are, if all you want is some kind of subtle non-distracting indications, you could just reverse video (or something similar) the extra edit locations. Indeed think of having a non blinking block cursor it completely obscures the text underneath depending on the contrast between its color and the text color. The blink at least lets the user makeout the text.

That said I am not dead set against this, if lots of people think this is a good idea, the protocol could be extended for it.

[neurocyte]

Flow Control now has basic POC level support in the master branch:

[kovidgoyal]

Nice, I'll work on adding support for a separate color for extra cursors
when I have some time. It should leave the rest of the protocol
unchanged, so your work will not be wasted.

[dnkl]

I'm wondering if using negative parameter values is a good idea. I don't think any other control sequences use them? And they are not recognized in https://vt100.net/emu/dec_ansi_parser, which I believe many VT parsers are based on?

(yes, foot will have issues with it since parameter values are currently unsigned. I can obviously change that, but if many parsers are going to have issues with it, perhaps negative values should be avoided?)

Since this is a new escape, there aren't any conflicts so there really shouldn't be a problem assigning other, positive values to them?