Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I think this going the wrong direction. Now, for example, when "goto definition" is requested we start some IPC or network action which can block and/or fail, and this is going to be a nightmare to debug. We don't know beforehand what will happen, like if the language server even provides any useful information.
I have been using @techee's LSP fork a bit and so far it hasn't failed at all. And on a quick glance ongoing it uses about 10-15% of my CPU (more on file open but only for a short time).
Instead I think we should use LSP to augment tagmanager so that we have all the needed bits within our problem space when "goto definition" is triggered.
That would mean significantly improving TM to contain things like scope of names which it does not handle in any form. The LSP is working with the program AST, its scoping is accurate, TM has none. Do you suggest implementing the AST for all languages in TM?
ATM all IDEs and editors are moving to LSP to leverage accurate information about the program content, including name visibility, handling templates (in C++), inferring types (C++ Python Rust Julia Go).
I think this going the wrong direction. Now, for example, when "goto definition" is requested we start some IPC or network action which can block and/or fail, and this is going to be a nightmare to debug. We don't know beforehand what will happen, like if the language server even provides any useful information.
Instead Geany runs a lower quality parser in between keystrokes and cannot improve it because if it took too much time it would be disruptive to editing.
The fact that LSP runs in a separate process means it does not interfere with the UI, and if it hangs/crashes it can simply be restarted, it won't crash Geany.
Instead I think we should use LSP to augment tagmanager so that we have all the needed bits within our problem space when "goto definition" is triggered. Then we can reason about the result. If tagmanager data store is not suitable we should make the necessary modifications there to make LSP realistic.
Thats not how LSP works, it does not export bulk information like a ctags parser, it answers individual queries, like "goto definition".
TM gives you more info than what you can obtain from LSP using its API
What extra does TM have? And what it does have is much less accurate information, no scopes, no inferred types (well thats ctags) and no template expansion.
I havn't looked at the detail of the API added, but it should be minimised, all API is a noose around our neck, it is never possible to change it since we have no process for removing it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.