> But you give me an opportunity to ask what I mostly missed on U-CTags: why > 0a99f9c? I mean, I get some of the additions, but not most of the changes, that were originally made for a reason, like the separate mem.c/file.c which was here to compartiment the backends and make the code easier to work with (originally it had the if/else style, but I went away from it).
I was a bit worried about how an additional library dependency would be received in uctags and whether it wouldn't be an obstacle to merging MIO (which is quite important for us because without it there would always be quite a large diff). So I tried to make things as little intrusive for uctags as possible (and about the opposite happened towards MIO itself) and converted it to "just another source file" which is part of the uctags tree and which style-wise resembles uctags (and which will be further maintained by the uctags project). I expected some opposition getting MIO into uctags (it's not _that_ important for uctags after all at least until it becomes a library) - but at the end the merge was quite smooth and fast (actually too fast so you probably didn't have enough time to comment and the big change I made was exactly the reason why I cc'd you to get some feedback). In short, the reasons behind most of the changes were mostly political, not technical. > Same, dropping GLib dep is nice for CTags, but instead of re-doing it, > upstream has it, and it's not a totally trivial change as a full MIO > implementation requires a conformant vsnprintf(), which is not so uncommon > but basically requires a conformant C99 implementation. Alright, I confess I didn't check upstream - I thought it was identical to the Geany version. > I'm not even sure MSVC has one (current docs seem to say it does though, but > vsnprintf() return value seem to have always be a problem on MSVC). Uctags uses appveyor (windows-based travis-like CI service) and it builds fine with MSVC so hopefully it's OK on Windows too (though I think it's actually never called by the code). > And if you wanna diverge too far from upstream (which is the case apparently, > also changing style and whatnot), that one should die and all the tests > should be imported into the new upstream. I don't really care what is upstream as I doubt anything else than Geany (and now CTags) use it, but it should then die in favor to becoming a part of CTags itself. Hard to say - your upstream version still might be interesting for someone who needs read/write from memory (but I'd guess there probably are more libraries like that out there, seems like a common problem at least). For uctags some of the functionality will probably never be used (like all the writing to memory buffer). There have already been some new commits on top of it in uctags and it started living its own life I'm afraid. But maybe it's not a big problem to have two MIO implementations - it's maybe slightly similar to the tagmanager case where we have diverged significantly from the upstream without updating upstream because it didn't make sense for upstream. I think the current state of MIO in uctags is quite stable so there probably won't be any too drastic changes needed related to the core functionality - and then we don't have to care about the uctags-mio much - it will be mostly the uctags project responsibility. That said, it might indeed make sense to somehow add the tests to uctags to make sure it won't degrade. Sorry if I caused too much mess with all this. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/1070#issuecomment-225619584
