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

[Thomas Martitz]

Am 30.08.2016 um 03:56 schrieb Lex Trotman:
> On 29 August 2016 at 22:38, Thomas Martitz <kugel at rockbox.org> wrote:
>> Am 29.08.2016 um 14:23 schrieb Lex Trotman:
>>> This adds per use case hooks to plugins, which then became part of the
>>> stable API. I don't think that we have to codify every single use case of
>>> tags into the plugins. That's just making it harder (maybe impossible?) to
>>> change or add use cases.
>>> The point of this proposal is to change and add use-cases that are not
>>> currently possible with the current plugin API.  But instead of each
>>> use-case generating its own piece of API and its own infrastructure,
>>> the point of the FT-plugins proposal is to provide a common
>>> infrastructure and approach for all filetype specific use-cases, those
>>> needed for currently suggested uses, indentation, clang based styling
>>> and symbols, and as framework for future use-cases we either havn't
>>> thought of, or havn't a concrete intention to add immediately.
>>>
>>>> I thought we agreed that plugin should simply provide tags to Geany/TM
>>> This proposal is about many types of filetype specific functionality,
>>> not just tags.  Tagmanager will not help in any way with indenting
>>> Haskell, or even C++.
>>>
>>
>> 4 of 5 of the proposed features are strictly tag-related. And Geany can do
>> all of them already, it's just that the current implementation leaves things
>> to be desired so there is the idea to let plugins improve upon them.
> Well, 3 out of 6 but whos counting :)


I count "Go To Declaration/Definition" as a tag issue. Where a symbol is 
stored,
and whether it's a definition or declaration, is contained in tags.

I did not count the build/run support, diagnostics and refactoring 
because there was no specific propsal given.

> 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 disagree with the proposed solution for those 4, because they are
>> offloading logic on a per feature basis to plugins, only because Geany isn't
>> capable at the moment. If Geany was capable, then there could be 1 solution
>> for the 4 features and less complexity in each plugin (and we know the
>> quality of plugins varies a lot so they should have little complexity as
>> possible).
> Encoding the knowledge of language semantics into Geany, for each
> language supported, is going to make autocomplete and calltip code
> look like c.c. Its not the way to go.

Nobody suggested to encode specific language semantics into Geany. I'm 
suggesting TM should become more generic, i.e. TMTag should transport as 
much information as required (even if some of it can't be provided by 
ctags but only some plugins).

>
>> The solution I have in mind simply allows plugins to pass tags to Geany
>> which they parsed with more advanced code. The tags itself would advanced
>> too, to allow for the improvements current TM+ctags can't offer. Symbol
>> tree, calltips, autocompletion, jump-to-decl can all be improved based on
>> the advanced tags.
> Well, again you are encoding language semantics into Geany, for
> example for C++ that means autocompletion and calltips need to handle
> 1) local symbol scopes, 2) member functions being in the scope of the
> class, even when they are not 3) argument dependent lookup 4) template
> expansion lookup and 5) handling of template parameter based typing.
> These are hard, just ask the GCC and clang guys.  And every user of
> Geany will have to pay the cost of the code they don't use, unless
> they use C++.
>
> Then for a multidispatch language like Julia you need to handle
> overloading in an even more subtle way than C++ overloading.
>
> And why re-implement these language specific subtle and difficult
> features in Geany when more and more languages are providing libclang
> like libraries to do it for us, accurately and up to date with the
> language.
>

Most of the issues don't apply to just C++ but so many other languages 
as well (e.g. Java). All of them can be improved more easily, not just 
C++, if Geany can offer a powerful framework for that. But the framework 
Matthew proposed is not powerful to me. It just evades the current 
problems simply by moving Geany's deficiencies to the plugin space.

Best regards