Why not refactor u-ctags to separate the parsers and parsing infrastructure from the command line and file writing stuff. That way such a library only includes parsing, thats the part most apps want and the library can be used by the u-ctags app of course :).

Yes, that would be the ideal long-term solution. And actually the writing stuff should probably be part of such a library too because some applications may want to write the tags files - it's just the command-line interface that should be separate. But doing this right means a lot of thinking about what the official API should look like and in the end may need a lot of refactoring so first I'd just try to bypass what we don't want to happen for Geany like the command-line interface add some missing functionality we need in Geany (and there's very little of new code, it's just something like 100 lines) and use the internal ctags API for now. I could create some dummy client application for uctags which uses the same functionality we need in Geany to make sure some internal change in uctags doesn't remove or break what we need.

Also apps need to be able to not build in parsers for languages they don't want, there are twice as many files in u-ctags/parsers as in Geany/parsers directory.

Yeah, but in this case it's our business to remove the parsers we don't want to get compiled like we do with Scintilla:

https://github.com/geany/geany/blob/master/scintilla/scintilla_changes.patch

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.