[Geany-Devel] [FT-plugins] Proposed "Features"

[Matthew Brush]

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