Support for multiple text cursors

[dumblob]

Based on the current version of the protocol, I got the idea, that it's basically impossible to transfer information about multiple text cursors.

Are there any plans for supporting multiple text cursors?

[svenefftinge]

Could you outline a use case? Even if there were multiple clients working on the same server (which will need some additional synching) a single request would always only need one pointer into the text, no.

[dumblob]

A simplest use case - one source code file (e.g. HTML) with just 10000 lines and you'd like to leverage the multiple-caret paradigm of editing (see
Kakoune, Sublime Text 2, Lime-text, Text-mate, Atom, Ultra-edit, Notepad++, PHPstorm, VisualStudio with MultiEditing plugin, etc.).

For both performance, convenience and user-friendliness reasons one doesn't want to send 10000 separate requests to edit each line of the source code.

Of course, there are multi-caret implementations which are constrained and allow placing caret only at one place and all the other places have to mimic this first placement, but e.g. Sublime Text 2 as the biggest advertiser of this feature doesn't do so and carets are truly independent.

[svenefftinge]

thx, got it. I thought it was about collaborative editing.

[dbaeumer]

@dumblob what is supported today is to send one change requests which describes 10000 edits. Although that is still overhead it doesn't send 10000 requests.

[mickaelistria]

I still don't get what's requested. Assuming the user has a hundred caret implemented, what kinds of operation have to care about it? Do you want to show all completions, all hovers, all code-lens simultaneously for all those carets?
Also, with the current API, you can also merge those multiple edits from multiple carets into a single one as @dbaeumer , sending all atomic changes, or just sending the whole changed document.

As far as I could see so far, the multi-caret (or "block selection" as it's called in Eclipse) paradigm is on the editor side, not on the content assist part. And the integration of the editor with the language server should take care of optimizing the requests according to the changes that actually happened (ie factorize a single change event for a multi-caret edition).

[dumblob]

@mickaelistria take a look e.g. at some YouTube videos (or http://kakoune.org/ ) about multi caret operations (selections, search & replace - e.g. using regexes, complex alignment of code, context-based coloring in reaction to the span of selections, etc.). The worst thing is, that users of multiple carets use them in highly specific, nearly unimaginable, ways and rely on support for virtually any set of operations. First then the multi caret "paradigm" becomes so strong.

Also, 10000 changes in one request is still a huge overhead, so a higher-level description ("this is a multi caret operation with properties x, y, z") should be the way to go (based on the aforementioned diversity of operations, factorization won't help much).

[mickaelistria]

Ok, however, I'm unsure about whether it's in the scope of the language server. The language server, as it is defined at the moment, is mostly about operations that are specific to a given language. The operations you mention (selection, regexes and so on) are plain text operations, which may be a bit out of the scope of the protocol.
I think if we want to go further on this topic, you'll have to list which operations of the current protocol could support multi-caret and what it would mean to invoke this operation on multiple carets or discontinued selections.

As the editor can assign different meaning for multi-caret (I imagine sure that Sublime and Kakoune have some divergence for example on some multi-caret operations, for example on how to handle a "move up" of multiple selected areas with different sizes), how can the language server know how the editor has implemented a multi-caret operation and what will be the resulting text?

IMO, things will work better if they remain separated: if it's plain text management, then it's the responsibility of the editor; if it's language-specific, then it comes from language server.

[bruno-medeiros]

@mickaelistria I agree. This issue seems like something that should be completely agnostic to the language server.

[dbaeumer]

I would like to keep the server agnostic to this. However we had a comparable discussion lately in the team as well what it means to request certain language features in the case of multiple cursor. We couldn't come up with a good answer so (e.g. show code completion for all cursors doesn't make much sense). So VS Code has currently the concept of a master cursor for which we request the operation. But I am open to expand the protocol to more than one cursor if we can do that for a specific use case to collect expierences with this (if someone wants to prototype this then he can always send n requests on the same document content with different positions in the document)

[dumblob]

@mickaelistria @bruno-medeiros thank you for your comments - I agree with the idea of separation of "responsibility", but already now the separation in case of other features is not so clear. I'm convinced the generic (language agnostic) proposal "this is a multi caret operation with properties x, y, z" with a list of multi-caret operations and their clear definitions should be the way to go for a protocol specification (think of RFC).

@dbaeumer thanks for pushing this further. This is the main difference between architecturing a protocol and an application. Application should implement current needs and should not implement "eventually useful features" (because application is for a specific use case as you mentioned). But on the other hand, a protocol has to handle all possible cases gracefully (be it with supporting it or completely publickly rejecting it - think of the HTML specification extreme issues for about two decades before introduction of HTML5) and especially when there are already many existing applications supporting the feature. And it's getting yet more important when the protocol should allow unification of interaction of these applications/clients.

Based of this, I'm leaving this issue opened.

[dbaeumer]

I will close this as out-of-scope since I don't see getting any traction for this soon.

[vscodebot]

This feature request will not be considered in the next 6-12 months and has been closed to keep the number of issues we have to maintain manageable.

Thanks for your understanding and happy coding!