[Geany-Devel] [FT-plugins] Proposed "Features"
mbrush at xxxxx
Wed Aug 31 00:29:57 UTC 2016
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
> 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
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.
More information about the Devel