-
Notifications
You must be signed in to change notification settings - Fork 808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
client->server request: Join Lines #992
Comments
@jrieken FYI. |
I'm not sure if I would like a text-oriented operation to be dependent on a language server. Why can't I use the regular join lines followed by a code action? |
Using code action is certainly possible (you don't even need regular join lines, you can fold everything into code action). However in my experience as a user of IntelliJ, dwim "text-oriented" commands (enter, open line, join lines), if implemented correctly, can create a significantly better flow of development. Here's a nice example from Enter in Kotlin: I am pretty sure that there will be users who'd love this, and users who'd hate this. My gut feeling is that the first group is bigger. From the protocol point of view, I'd think that we should unlock opportunities to precisely tweak user experience, rather than prescribe a specific way of doing things. Severs are free to not use the opportunities, users are free to disable specific features they feel are getting in the way. |
I get that it's cool to have that functionality, but your above GIF would be implementable by a simple snippet. |
I strongly disagree here: snippets indeed can be used to insert the same text, but it’s not the point. The point is dwim experience during basic editing operations, and that, by definition, can not be replaced with explicit user actions. See also https://github.com/JetBrains/kotlin/tree/master/idea/src/org/jetbrains/kotlin/idea/joinLines which defined Kotlin’s custom behavior for join lines. There’s quite a bit of code there, and it can’t be replaced by simple snippets/code actions/etc. It can be argued that having those features is not important/detrimental, but that would have to be a different argument than “we already can simulate them well enough”. |
I don't know if it matters to you but i'm almost 100% certain i would not implement this in my client. |
Meta: I am in the process of formalizing protocol extensions, used by rust-analyzer. I will be filing issues for generally useful extensions. Here's the doc where we will document our extensions.
joinLines
Server Capability:
{ "joinLines": boolean }
This request is send from client to server to handle "Join Lines" editor action.
Method:
experimental/JoinLines
Request:
Response:
Example
experimental/joinLines
yields (curly braces are automagiacally removed)Unresolved Question
joinLines
?Currently this is left to editor's discretion, but it might be useful to specify on the server via snippets.
However, it then becomes unclear how it works with multi cursor.
The text was updated successfully, but these errors were encountered: