Language Server Protocol (LSP) support

Want to suggest an idea for a new plug-in? Know for sure what is needed for plug-in X to become the best? Write here.
Post Reply
tifftoff
Posts: 4
Joined: Mon 04 Mar, 2019 12:49

Language Server Protocol (LSP) support

Post by tifftoff » Mon 04 Mar, 2019 19:46

Far would make a giant leap if there was support for language servers (search for language-server-protocol).
An editor plugin that supports code completion, navigation to definition, find references, symbols for current file (outline) or workspace, error markers etc.
With such a plugin, tons of currently freely available language servers could be integrated and Far would become a true alternative as an IDE.

What do you think?
:Yahoo!:

tifftoff
Posts: 4
Joined: Mon 04 Mar, 2019 12:49

Language Server Protocol (LSP) support

Post by tifftoff » Mon 04 Mar, 2019 19:58

Not sure if all russian developers check the english forum.

Could someone translate this and post it in the russion forum as well, pls. Thanks a lot!!!

Yegor
Posts: 957
Joined: Mon 04 Apr, 2005 13:41
Location: San Ramon, CA / Kharkov, UA
Has thanked: 3 times
Been thanked: 12 times

Language Server Protocol (LSP) support

Post by Yegor » Mon 04 Mar, 2019 20:04

I think it is a nice idea, but you have to find a person who will be willing to implement it.
Мы не можем ждать милостей от Фара, взять их у него — наша задача! (C) Мичурин

tifftoff
Posts: 4
Joined: Mon 04 Mar, 2019 12:49

Language Server Protocol (LSP) support

Post by tifftoff » Mon 04 Mar, 2019 20:24

I'm definitely willing to take part. I'm a developer but have never written a plugin. Though, having experience with the LSP. I wonder what language options there are these days. Delphi or C++ is not feasible for me. Personally I could think of LUA or C#/.Net. Has anyone experience with the two latter? Are they a good choice? I mean concerning integration, memory footprint etc.
Is node.js also supported in the meantime?

Yegor
Posts: 957
Joined: Mon 04 Apr, 2005 13:41
Location: San Ramon, CA / Kharkov, UA
Has thanked: 3 times
Been thanked: 12 times

Language Server Protocol (LSP) support

Post by Yegor » Mon 04 Mar, 2019 21:01

You can try to write a module in C# via FarNet (https://github.com/nightroman/FarNet)
Мы не можем ждать милостей от Фара, взять их у него — наша задача! (C) Мичурин

User avatar
HaRT
Moderator
Posts: 8639
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 78 times
Been thanked: 142 times

Language Server Protocol (LSP) support

Post by HaRT » Mon 04 Mar, 2019 21:45

tifftoff wrote:
Mon 04 Mar, 2019 20:24
Personally I could think of LUA
Lua is a perfectly valid choice to implement a new FAR plug-in. See https://github.com/shmuz/far_plugins for examples; if/when stuck, post your questions to the “Plug-In Developers” sub-forum (use Google/forum search to find the answer first).
Last edited by HaRT on Mon 04 Mar, 2019 21:45, edited 1 time in total.
Фар есть инструмент, а не нянька. © 2009 DrKnS

tifftoff
Posts: 4
Joined: Mon 04 Mar, 2019 12:49

Language Server Protocol (LSP) support

Post by tifftoff » Mon 04 Mar, 2019 22:46

Thanks for the input.

A little investigation gives:

LUA:
Far API: github com/shmuz/far_plugins
LSP (server with RPC and methods): github com/Alloyed/lua-lsp/tree/master/lua-lsp

C#/.Net:
Far API: github com/nightroman/FarNet/tree/master/FarNet
LSP client: github com/OmniSharp/csharp-language-server-protocol

Hmm, my first impression is that .Net looks more complete, especially the LSP client part makes it attractive.
LUA on the other hand doesn't need recompilation which may speed up development.

Any comments on this?

User avatar
HaRT
Moderator
Posts: 8639
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 78 times
Been thanked: 142 times

Language Server Protocol (LSP) support

Post by HaRT » Mon 04 Mar, 2019 22:52

tifftoff wrote:
Mon 04 Mar, 2019 22:46
Any comments on this?
Another advantage of Lua is that it is a native scripting language of FAR, so the plug-in will also be able to benefit from Macro API in addition to the Plug-ins API.
The disadvantage of .Net is that the framework will need to load into FAR which will make a significant footprint it terms of both startup time and memory usage (known by the VDISK module to the Observer plug-in).
Фар есть инструмент, а не нянька. © 2009 DrKnS

Post Reply

Return to “Suggestions and Ideas”