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 :)