[Geany-devel] tagmanager changes

[Nick Treleaven]

On 29/04/2012 15:47, Colomban Wendling wrote:
> Le 26/04/2012 18:53, Nick Treleaven a écrit :
>> On 26/04/2012 16:02, Nick Treleaven wrote:
>>> On 24/04/2012 22:31, Colomban Wendling wrote:
>>>> * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
>>
>> BTW this is a good idea to clearly separate CTags from tagmanager. If
>> this change can be applied separately, perhaps it could be merged into
>> master.
>
> It should be quite easy -- though it won't still be a vanilla CTags of
> course, my own isn't either (yet?).

I just thought it was a separate change from the TM rewrite.

We have a lot of changes from CTags e.g. new languages and improvements 
to existing parsers (and even CTags itself) which IMO we can't throw away.

It is possible to merge some changes from CTags but for e.g. c.c this 
has become pretty difficult. I tried this once but it ended up breaking 
the parser and I didn't work out why.

IMO the biggest issue with CTags is that it isn't really maintained and 
they rarely accept patches even when it fixes an important bug (e.g. a 
fix to regex callback parsing with ignored matches).

>>> For avoiding resorting of workspace tags when only reparsing one source
>>> object, we can remove the source object's old tags&  merge the new tags.
>>> This is all O(n) for the workspace array. I haven't looked into
>>> implementing this yet because now it's clear you're working on a
>>> competing change.
>>
>> Another option is to remove the workspace array altogether and just have
>> Geany collate tags from each (sorted) source object when needed. Not
>> sure the implications of this yet but it would simplify tagmanager.
>
> Well, tagmanager needs to know all tags to perform e.g. scope completion
> beyond file's boundaries.  And for search too, it would need us to pass
> it everything, or to perform a search on each document's tags and then
> merge the result.  Doesn't sound sensible at a first glance, but maybe
> I'm missing something.

It comes to a trade off between merging/sorting results from multiple 
tag arrays and merging/sorting the whole workspace array even when only 
one document is reparsed.

Actually I suppose the first one can cause lags which the user could 
notice if there are a lot of results, whereas the second one only causes 
problems on reparsing, which is less often than searching.

I'm undecided. The second one can be more serious if the calling code 
doesn't handle e.g. save all specially and the workspace array size is 
quite big. The special handling is to not update the workspace array 
until all documents have been parsed, then to resort it. If it's only 
save all, we can cope, but there may be other ways this can happen.