Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mutex type prefixed with (*Mutex) while with our TMTags we'd have this in scope
Well, bearing in mind the limitations of my Go, I think what it is telling you is that the Mutex needs to be accessed via pointer, all users of a Mutex must access the same memory, they can't be separate instances. And thats how the docs present it here
pylsp generates what we call "local" tags (for variables inside functions) but we have no indication from the LSP server that these tags are local (which we'd need for correct autocompletion).
Yes, I noticed that, Python assignment is also a variable declaration remember, so it clearly takes all assignments as declarations. Using my example scripts/create_php_tags.py the local tag_list does not appear in the ctags symbols but does in the LSP symbols.
For example type tag_ (properly indented, its Python remember) on blank line 77:
The TM/ctags autocomplete is a long list but starts with tag_list, where it got them from I don't know. It has no scope autocomplete after accepting tag_list.
But the LSP autocomplete is 3 entries, only the local tag_ names, including tag_list, and then has scope autocomplete of the methods of a list. Similarly arg_list has string methods autocomplete in LSP but nothing in TM/ctags.
Tthe LSP does autocompletion for variables it can trace values and types for (being dynamic Python makes that a bit hard unfortunately, therefore many variables have unknown types), "we" don't need to do autocompletion if LSP is running, and if it isn't then its TM/ctags only and no LSP symbols to care about.
On the other hand, clangd doesn't provide local symbols at all unlike our TM cxx parser.
It doesn't give locals because they are not visible outside a lexical scope from the declaration to the end of the block its in, except for class members in member functions which can be visible before the declaration and also inside member function definitions written outside the class definition, even in another file, and how do you express that? But doing anything for a symbol outside that scope is wrong, the symbol is not visible. The LSP server does the autocompletes and hovers for them, so it has the information internally. And scope autocompletion even if they are inferred types, which ctags can't do.
So if we want to unify TMTags with what is returned from LSP servers
We can't unify them, full stop. Its an either or situation I'm afraid. As I said above, the LSP knows about the lexical scope of the symbol, but has no way of passing that to TM and TM has no way of representing it anyway. Thats why LSP de-emphasises the symbol list, it cannot reasonably be right for functions like autocomplete or gotos.
Perhaps a better way would be to consider if the LSP functions can be available to plugins, but then the asynchronicity might be a problem.
Back to the API - should it be specific for the LSP usage or more generic so it can be used by other plugins?
but I don't see much use for such deep integration myself especially when we still want to keep using the TM.
How do you handle multiple plugins trying to provide the same function? This is the first glimpse of plugin provided language functionality and devolution of all language specifics to plugins, like every other IDE, but while its only one plugin lets keep it simple, as I told @b4n "at this stage, the full takeover is later" ;-)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.