About Naming Conventions
I have observed that the asynchronous method names in the API do not follow the conventional pattern of including the 'Async' suffix. This could potentially lead to less intuitive method naming. Is there any intention to revise the API names to better reflect their asynchronous nature?
This is indeed a best practice, but the asynchronous APIs in the project do not have corresponding synchronous APIs. Additionally, it is reasonable for the API itself to have the same name as the LSP request. Overall, changing the API is reasonable but it is a breaking change and not very necessary.
This is indeed a best practice, but the asynchronous APIs in the project do not have corresponding synchronous APIs. Additionally, it is reasonable for the API itself to have the same name as the LSP request. Overall, changing the API is reasonable but it is a breaking change and not very necessary.
Thank you for your reply. Additionally, I have a question to ask you. I am a novice in networking, so I would like to know: What are the significant differences between using TCP, named pipes, or stdio for communication between an LSP (Language Server Protocol) client and server?
There is no significant difference, but the majority of LSP clients only support communication with the language server using stdio. Additionally, supporting TCP communication is more suitable for debugging
I am now preparing to develop a VSCode extension. If I want to use the IPC protocol for communication, can I use this library? Can IPC also be debugged as conveniently as TCP?
You can definitely support multiple communication methods. Refer to the LanguageServer.Test I wrote. Additionally, I am not sure if IPC can be used as a stream by the LanguageServer. If not, you can write your own LanguageServer. I recommend only using stdio and TCP communication methods
I learned from AI that IPC has lower overhead compared to TCP, which is why I decided to use IPC. However, despite my efforts, I have not been successful so far.
My apologies for bothering you again, but I'm not sure how to make VSCode emit DidChangeTextDocumentParams.
I've set the capabilities in OnInitialize,
ls.OnInitialize(
(c, s) =>
{
c.Capabilities = new ClientCapabilities()
{
TextDocument = new TextDocumentClientCapabilities()
{
Synchronization = new TextDocumentSyncClientCapabilities()
{
DynamicRegistration = true,
WillSave = true,
WillSaveWaitUntil = true,
DidSave = true
}
},
};
s.Name = "EmmyLua.Test";
s.Version = "1.0.0";
Console.Error.WriteLine("initialize");
return Task.CompletedTask;
}
);
but it hasn't worked. What should I do?
but it hasn't worked. What should I do?
The capabilities do not need to be registered in the initialize method, and your registration method is incorrect. You only need to addHandler and register within the handle.
see: https://github.com/CppCXY/LanguageServer.Framework/blob/main/LanguageServer.Test/Handler/TextDocumentHandler.cs
Thank you, it is now running properly.
I think that major overhead comes from the need of keeping the LS protocol-specified format of messages and constant JSON encoding and decoding, so using IPC over stdio would not yield much of a performance increase. Since VSCode runs its client side as a javascript application, performance gain is further nullified.