[Geany-devel] tagmanager changes

[Colomban Wendling]

Le 30/04/2012 19:07, Nick Treleaven a écrit :
> 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.

It could very well be I think, basically it only changes the directory
structure a little.  I'll try to replicate this on TM.

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

Yes, we can't use stock CTags everywhere.  Because we have some changes
that aren't applied upstream, and then merging would be a mess (sadly).
 And a bit also because TM changes a few things in a few CTags files to
"plug" into it -- necessary unless the parsing is done by calling the
ctags executable; which isn't necessarily better.

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

(unless real-time tag parsing is enabled)

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

If TM (could) have an API for that it'd be fine, but I don't think it's
a really good idea if it becomes a hack.