Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@techee good on you for giving this a go.
Whilst I agree with @techee that there should only ever be one LSP plugin because LSP is itself an API intended to be extensible so there is no real need for another (so long as we guard against "all languages are C" assumptions creeping into it), for now starting this as a separate plugin is a good idea, 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, colouring etc. Then it can be promoted to Geany, if @techee wants to, there are of course plugins that are not submitted to Geany, its the developers choice.
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, which can discourage adding those features. 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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.