On 2016-08-30 02:29 PM, Thomas Martitz wrote:
Am 30.08.2016 um 21:10 schrieb Jiří Techet: [...]
And even if we did this, I don't know how we could handle ASTs of different languages in a generic way because these will differ significantly.
One more time, seems I wasn't clear enough yet: I'm *not* suggesting that we create generic code inside Geany that handles any kind of AST. What I suggest is that plugins that use AST internally (or not) pass tag-like information to Geany, extracted and flattened from its internal AST (or whatever it uses). Then Geany and other plugins can use that information for their own purposes.
We do need more than just "tags-like information" though, for example, what's Geany gonna give for completions here (C++):
auto bar = foo<X>()->...
Or even on the next line:
bar.blah = baz... + 3
In the first case, it needs to know the type of not only `foo`'s return value, but it needs to know the type of `foo<X>`'s return type (could depend on `X`'s type and/or lots of other stuff).
For the second line, a super-smart auto-complete might only give suggestions for a `baz` that has a type that has an `::operator+` member that works with ints (or `baz` is a primitive numeric type), what's more, it could also filter the suggestions down so that it only shows identifiers (in any accessible scope) which start with `baz` and when the global or member `::operator+` is applied to it and 3, and the result of that which is also compatible with the `blah` member of `bar` (which is the type of the return of `foo<x>()` and never even mentioned locally).
As a further example, if we ever upgrade Geany's auto-complete list to be more than Scintilla's default (to something similar the one in GtkSourceView IIRC), which say for example showed the doc-comments for a given symbol (something libclang provides in/along with the AST, and is also accessible in Python AST as well, IIRC), not only now does TagManager have to store all that comment text (redundantly, or else call into the ft-plugin to get it on demand), but it has to pick-out the _exact_ right completion for the comment to be correct, based on all kinds of factors, such as the language's scope lookup rules (even inside of `if` blocks, which it also now has to store in the Tags array or recover from the source code some how), but also based on templated types once interpreted (TM would need to store some kind of decypherable mangled names after templates are expanded), and overloads (which it would need to determine given the given set of overloads, based on argument types which compile (and also SFINAE and all that jazz), and inheritance rules (TM would need to keep track of polymorphic, potentially multiply-inherited relationships), etc.
Basically, TM would have to have a semantic analyzer with the strength of that of a real compiler, for each language an ft-plugin might implement. That is what's needed for real Intellisense-like features and I believe what some of the responders are getting at. The same kind of smarts would be needed to also implement calltips or goto def/decl, though perhaps with slightly different logic.
What's more, for the specific libclang case, since it's meant to be used as a support library for IDEs (and other tools), it already provides a function like `completeAt(where, ...)` for auto-completion that when called provides a list of AST nodes referring to the valid completions at that point. It would be horrible to have to re-implement that function independent of the AST in TM/Geany, instead of just passing Geany a list of strings or TM tags to show in the popup list.
Cheers, Matthew Brush