"Library" in ctags may have 3 aspects:
The scope is this issue is "3. running ctags."
Decreasing global variables will be the initial step.
The text was updated successfully, but these errors were encountered:
@b4n, who is the primary maintainer of geany/tagmanager /ctags?
I'm looking for the way to share our efforts.
My idea is that splitting the source code of fishman/ctags into 3 parts.
Of course "parsers" is the initial target for merging.
About geany side my request is:
Then we can evaluate, compare and exchange "parsers" code each other.
How do you think this approach?
From what I can see, Geany just included the files they need (base and parsers), modified them and set the variables/options to their need. But @b4n should be able to tell us more.
Keeping the parsers synced in some would be great and we both would benefit from that.
As I wrote in #83 Geany modifies their kindOptions. For instance, compare the two pascal parsers. We have two type: "function" and "procedure" and Geany has more of less merged them to "function". This kind of adjustments appear in other parsers as well. I guess this is to create a more uniform way for them to show the tags. But again @b4n should be able to tell us more.
@vhda, yes, you are right. We can send the same proposal, introducing "parsers" directory to exuberant-ctags.
If there is conceptual gap, like kindOptionas reported by @ffes, beetwen Geany and fishman-ctags, I will work on Geany side to fill the gap.
Anyway, let's think separate core and parsres. I believe the efforts for parsers can be share easily.
Sorry for the delay. At the time I didn't have time to answer correctly, and then I forgot about it… err.
What Geany does (through TagManager that was a very old library used by Anjuta a long time ago AFAIK), is simply call in
We however support in-memory parsing, to be able to update displayed tags as the user types without having to write temporary files all the time. For this purposed, I wrote a tiny library named MIO, that supports file or memory-backed I/O with very low overhead and an API very close to the C FILE API to simplify porting.
Sure, for the parsers part I'd be happy to. I already do most of the work on Geany's side, so I can do it here too.
I am, mostly. I'm the maintainer for Geany, and the most active developer on the CTags part.
That would be awesome of course, the less diverged our tree is from upstream the easier it is for importing in both directions.
We could very well of course, and it would slightly help in differentiating the files, but that's probably not the worse part of the job :)
That's it, basically. We try to do the fewer modifications we can so importing upstream changes is easier, so again, we should be mostly in sync here, but for a few parsers.
Yes, we change the kind names to be able to map them easily to generic entity types (TMTagType). CTags parsers are really not unified in this regard (which may or may not make sense, but some languages do have other names for things), and we need to be able to recognize at least some types, like functions/methods/prototypes, no matter what they are called in a particular language.
There could be other solution for this mapping problem, like we could probably have a mapping table to translate those in our side rather than in the parser itself.
I like the idea of mapping table. I call it "flavour".
I would like to hear from you about two more topics.
Sure, no hurry.
They are, they are the expected results from the parser. However, Geany uses the TagManager format, which introduces fields with binary identifiers. See
I honestly don't really know the state of the core ctags we use, but it surely have its fair share of global variables. We corrected some of the global variable issues in some parser, but only to make them re-usable because some had problems when called for the second and next times; but I believe CTags also suffers from this when parsing multiple files, it may just be a little less obvious -- and I also believe most of these issues have been fixed here too.
About threading, yes global variables are indeed a problem. However, my (little) experience trying to run parsers in threads showed that it was mostly good enough to use one single worker thread calling all parsers, and for this global variables aren't a problem.
So I believe that threading is not the primary concern for creating a CTags library, I think that at least at first it would be good enough for the application to use it from one single thread, it being the main one or a dedicated one is the application's choice anyway.
Of course it'd be a different story if you wanted to provide a library that also manages the set of parsed tags and allow to manipulate them (search for a tag of a particular name, tags with a particular prefix, children of a tag, …), in which case indeed allowing this to be multi-threaded out-of-the-box would be awesome.
Instead of qsort() it's possible to use g_ptr_array_sort_with_data() with similar performance. Unfortunately it seems there's no bsearch_with_data() anywhere so the patch uses a modified bsearch() implementation from libc (still probably cleaner than passing arguments using static variables).
@dtikhonov Well, first, I didn't know about it :) Then, and probably a reason why I didn't find about it at the time (2011), it's not very portable (in POSIX.1-2008 but not before, otherwise seems to be
So it'd be very nice, but I'm really not sure it's an acceptable dependency (would have to be checked on all platforms, also for consistency as if it's pre-POSIX, it's likely to have slight inconsistencies -- and we can't really reimplement it where missing as FILE is totally opaque).