You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 14, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 14, 2022. It is now read-only.
Implement auto indentation when pressing the : or Enter keys #671
Today indentation of code is implemented within the extension (and buggy, as we do not have the token/AST information, etc)
The C# extension supports similar features (indentation changes) when you type the character }.
The C# extension is TS code, that sends requests to a .NET process over a protocol.
I.e. .NET is performing the necessary formatting, and sending back the formatted code (asynchronously) back to the TS code.
We need the same thing, when users type the character :.
I.e. TS can send a custom request to language server, get the response back and send formatted code to VSC.
I.e. if C# extension (using the .NET code, async communication via a protocol) can do this, then how about we do the same thing (using LSP over custom request).
Omni is not using LSP. They have regular TS extension which then runs their process manually and communicates with it via custom protocol. This is not technically a language server at all. Omni was implemented way before LSP was born.
When actual LS/LSP runs the extension TS/editor part is bypassed and requests go directly to the LS process.
Therefore what you are asking is a way to get to LS while actually VS Code did not launch it. This can be done at the extension side - start the process and perform similar connection hookup as VS Code performs internally in regular LS scenarios. Then send and receive requests either via LSP or via custom messages.
This is basically a hybrid solution. There may be other cases such as get syntax errors from the parser without actually switching to LS.
Omni is not using LSP. They have regular TS extension which then runs their process manually and communicates with it via custom protocol. This is not technically a language server at all. Omni was implemented way before LSP was born.
Agreed. I just see it as a separate process that ts extension communicates over some protocol.
When actual LS/LSP runs the extension TS/editor part is bypassed and requests go directly to the LS process.
Yes, but we can still send custom requests via the language client, and that's the plan. No changes.
Therefore what you are asking is a way to get to LS while actually VS Code did not launch it.
No, we'll let VSC launch the language server as done today. No changes there.
All, we'll do is use the language client and send a request (we already do this today), so architecturally, no changes.
The only exception would be we'd probably send a custom request to the LSP.
FYI - we already send requests manually to LS from extension code manually.
This is basically a hybrid solution. There may be other cases such as get syntax errors from the parser without actually switching to LS.
Not really, we'll only do this for language server, and not when using Jedi.
We will not change how LS is loaded.
I mean that when LS is up you don't get requests for completion, tooltips, etc in the TS part, they bypass the extension and go straight to LS. I.e. TS 'completion provider' is mute. Do you still get requests for the indentation?
Got it. No that doesn't work.
Also double check with C#, the auto indentation of } is done by VSC and not C#.
I.e. disabling formatOnType doesn't provide what we need.
Back to square one.
Activity
MikhailArkhipov commentedon Feb 27, 2019
Omni is not using LSP. They have regular TS extension which then runs their process manually and communicates with it via custom protocol. This is not technically a language server at all. Omni was implemented way before LSP was born.
When actual LS/LSP runs the extension TS/editor part is bypassed and requests go directly to the LS process.
Therefore what you are asking is a way to get to LS while actually VS Code did not launch it. This can be done at the extension side - start the process and perform similar connection hookup as VS Code performs internally in regular LS scenarios. Then send and receive requests either via LSP or via custom messages.
This is basically a hybrid solution. There may be other cases such as get syntax errors from the parser without actually switching to LS.
DonJayamanne commentedon Feb 27, 2019
Agreed. I just see it as a separate process that ts extension communicates over some protocol.
Yes, but we can still send custom requests via the language client, and that's the plan. No changes.
No, we'll let VSC launch the language server as done today. No changes there.
All, we'll do is use the language client and send a request (we already do this today), so architecturally, no changes.
The only exception would be we'd probably send a custom request to the LSP.
FYI - we already send requests manually to LS from extension code manually.
Not really, we'll only do this for language server, and not when using Jedi.
We will not change how LS is loaded.
MikhailArkhipov commentedon Feb 27, 2019
No, we'll let VSC launch the language server as done today. No changes there.Do you still get requests for the editor functionality when LS is running?
DonJayamanne commentedon Feb 27, 2019
Not sure what you mean. But we have the ability to manually send requests to the LS, and we do this today.
MikhailArkhipov commentedon Feb 27, 2019
I mean that when LS is up you don't get requests for completion, tooltips, etc in the TS part, they bypass the extension and go straight to LS. I.e. TS 'completion provider' is mute. Do you still get requests for the indentation?
DonJayamanne commentedon Feb 27, 2019
Got it. No that doesn't work.
Also double check with C#, the auto indentation of
}is done by VSC and not C#.I.e. disabling
formatOnTypedoesn't provide what we need.Back to square one.