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

[Colomban Wendling]

Le 30/08/2016 à 17:31, Thomas Martitz a écrit :
> Am 30.08.2016 um 03:56 schrieb Lex Trotman:
>>> […]
> 
>> Certainly 1) showing symbols in the symbol list, 2) autocomplete and
>> 3) calltips are currently available to a degree in Geany.  But
>> highlighting, build commands and build result handling are not.
> 
> 
>> But
>> to be able to do 2) and 3) accurately needs more knowledge of each
>> language semantics than is currently available in Geany or tagmanager.
> 
> That's right. But it doesn't mean the features should be *entirely*
> moved into plugin space. TM should be improved to be able to hold
> sufficient information, and plugins should help by providing that data.
> But *just* the data, don't offload very specific use cases onto them,
> this will make us less flexible in the long run. If Geany has the data,
> we can implement new features inside Geany or non-ft-plugins. Otherwise
> we would have to modify every single ft-plugin for new features and
> exclude non-ft-plugins.

I don't think the real problem for the current state to really only be
about what tags are generated.  Sure, if tags for local variables were
generated, scope completion would become more useful just like that
indeed.  And then, the current code should only be improved to properly
use the tags to show completions.

But this doesn't take into account several language specific things, like:

* what is an identifier? (for looking up what to complete)
* what is an argument list? (for showing calltips)
* what are the scope semantics?
* …

Sure, some of those can be implemented generically using TagManager
capabilities with appropriate tags, just by improving the generic code.
But that means scope semantics are always the same, or are pluggable,
and same for the other details.

Yes, I'd love TagManager (and our use of it rather) to be as good as it
can get, and it could get pretty far (like what I tried with that
"visible in current scope" patch in the scoped calltip PR).
It's not trivial (like requires to know all the imported namespaces and
stuff), but it's doable if all languages can fit in the same jar [1]

But if a language has totally different semantics than, say, C++, we'd
be pretty much screwed no matter how good the C++ semantics were.

Also, I think Matthew pointed out that in any case, to get perfect
completions we'd need prefect tags, and that we'd have to check how fast
it is with virtually an infinite set of tags (Jiří?).  But that's indeed
not a concern to have now.


Anyway, my point is that I totally agree that we should try to get TM
completions to the best they can be, but that no matter how good it is
won't ever be as good (well, at least not better) than completely
specific code.  So I think Matthew's goal of allowing to *replace* code
deciding what to complete makes sense.


Regards,
Colomban


[1] I don't know the English expression, so I built one that sounded nice :)