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. _______________________________________________ Geany-devel mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
