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.