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

[Matthew Brush]

On 2016-08-29 05:38 AM, Thomas Martitz 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.
>
> 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).
>

Using TagManager would likely add more complexity to the plugins. Using 
the libclang example, it already has its own internal representation of 
"tags" (ie. the AST). Making plugins munge their internal representation 
to convert/conform to TagManager's would add extra burden.

For example "go to definition/declaration" is a simple task with 
libclang, you would just get the source location and pass back to Geany 
the filename and position and it could go there easily, without any need 
for TagManager as a middle-man. Likewise, libclang has a function to 
return valid completions for a given position in the source code, 
passing a list of strings for Geany to show in the Scintilla 
auto-complete list would be a simple matter of building a string array. 
Using tag manager would require building a tags array that probably 
wouldn't/shouldn't become part of any larger tags array 
(workspace/global/whatever) and then getting Geany to show that tags 
array without messing with it (ordering, etc).

Another issue that might arise is that TagManager might very well choke 
if it had to deal with every single tag/symbol in the entire source 
(make a "hello world" in C++ using iostream and look at the preprocessed 
source, for example). The number of tags it would need to store/track 
would way more than double when you consider local variables, 
parameters, inner-classes, etc. I have no clue if TM is actually able to 
handle this at all, efficiently enough. Ontop of that, all this 
information is stored twice in memory, once in the libclang AST and once 
in TagManager tag arrays. This could result in quite some additional 
memory overhead.

Jiří gives an example (the symbols sidebar) where this may be warranted 
and ultimately cause less work, since the sidebar updating code is 
apparently quite complicated. I still need to study this code to 
understand why so much effort is needed to keep the symbol tree at the 
same relative scroll location when updated.

> 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.
>

I'm not strictly opposed to wrangling stuff through TagManager. Could 
you provide example hooks showing the kind of interface you would 
thinking about for the mentioned features? Also in which cases do you 
expect TagManager is not up to the task and would need to be modified?

Cheers,
Matthew Brush