Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
it can be hacked and crashed and every other thing until it works reliably and supports most/all of the lsp API, eg didOpen, didChange, goto declaration/definition
All of them work (and the plugin is stable as far as I can say) but still I want to implement more features or possibly refactor some things so it's definitely far from complete.
Design question, at the moment its tractable to test feature availability before calling at each place its needed throughout Geany, but its going to become messy as more features are added,
The only one missing is the symbol tree - otherwise the feature set overlapping with Geany is complete so there won't be much more. Those extras in LSP that don't have the Geany tag manager counterpart don't have to be handled in Geany itself at all. I already implemented "diagnostic messages" and "hover" but since the whole Scintilla is exposed to plugins, the majority of features can be implemented without Geany assistance.
Instead can the Geany features also be wrapped in a function like the LSP ones and put as the default in the per doc (or is it per filetype?) function pointer table, so all anything ever has to do is call the function pointed to, the table will never have null pointers.
There are three problems with this:
Geany uses synchronous calls while LSP uses asynchronous communication. Geany expects that when you call a function implementing for instance autocompletion, it will happen when the function terminates. LSP, on the other hand, only sends a request to the server and when the function finishes, the results aren't available yet. Unifying it with Geany would mean we'd probably have to modify Geany to expect asynchronous results from the current implementations of these features (the only place where I'll probably do it is the symbol tree because the amount of code related to it is quite big and complicated and I'd like to re-use as much of its implementation as possible).
The logic behind the Geany's implementation of various features differs significantly. For instance, for autocompletion, there are multiple modes (non-scope, scope, document wordchars, something HTML-specific too) and the logic when autocompletion is triggered differs very much from how it's done using LSP (in LSP, you just have some "trigger characters" which, when typed, should make the client send the request to the server and the server either returns something or not). The logic in Geany involves checking what has been typed before the cursor and checking tags in the tag manager and other things. So it's hard to unify both the Geany code and the LSP code behind some universal interface.
I wanted to make the changes on the Geany side as little intrusive as possible. The code related to the tag manager is already complicated enough and having to think about one more mode of operation would complicate things. So the current code just disables Geany-provided implementation which IMO simplifies things.
so all anything ever has to do is call the function pointed to, the table will never have null pointers.
There will probably be just two more functions for the symbol tree now - the NULL pointers are really just in case we implement something using TM in Geany and we'll want to switch between LSP and Geany's implementation.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.