After merging #2132, I think I should stop introducing new code to ctags side.

I can only guess this is not exactly what you meant, because we certainly don't want to freeze upstream u-ctags, nor stop innovation. If you mean try and keep things stable, yes, it's best to maintain stable interface whenever possible, but it shouldn't prevent innovation.

@techee @masatake what about Geany's c.c having a lot of extra stuff (even extra languages IIUC)? I don't watch uctags much, but last I looked any attempt to import that was abandoned.

Well, that will definitely not be done by me :-). However, I think that the first step for Geany could be to switch to the new cxx parser for C/C++ and not to use the parser of these languages from c.c. Then the C/C++ portion of c.c could be removed completely and I think especially C++ contributes by the largest amount of code. The same could be done with the upstream c.c and it might be much easier to merge what remains.

It's probably something I'll look at at some point. I'll check, but I guess it'll end up splitting the different languages into separate parsers proper. I do even have a standalone Vala parser lying somewhere that just await a revival [1] so that part could be fairly easy and give Vala support a boost. Anyway, it's not my priority right now, but it might become so when we progress further enough towards a u-ctags sync.

Apart from that, I don't have much to add: yes, the ultimate goal should probably being able to simply link a libuctags, and in the meantime we should try and make it as easy as possible to keep Geany's copy of uctags in sync with upstream. I trust @techee to layout the required interface, as he's acquired a lot of experience here :)

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