Yeah, there is always going to be a tension between slow projects and fast ones where the interface is more than can be accommodated by a DLL (also where the dependency isn't distributed as a DLL). Same for Scintilla. In both cases its not just the function call API (that might be easy to make a DLL), but also the syntactic entity/tag types mappings.
IM(NS)HO separate them, if there is a PR that is solely a (not _too_ big) formulaic update to the ctags and all parser tests pass its possible it might get committed by someone other than one of the experts, thats the idea of @techee's approach AFAIK, you don't _have_ to be a ctags expert, just check nothing out of context is changed and accept that uctags is a fairly well managed project. That of course only works for infrastructure changes that don't cause changes to other parsers, which would appear to be the case here. And I would update to the latest that does not break any other parsers or change their mapping in symbols (and yes you are responsible for checking that, don't throw it on others if you want it to move fast). When its mixed I can't tell what might be a change that is part of your parser and whats infrastructure when I'm looking at changed files (ie the deltas in context) since github can only show that for the whole PR, not for individual commits AFAICT (grrrr). Again its a case of "don't make it hard to check if you want it to move", nobody has the time available to do big things. After the infrastructure update then the "Add Kotlin" update becomes relatively easy to check for major obvious things (which is all that it will be unless the reviewer knows your language). Also the more and bigger tests the better as non-[your favourite language here] users will have more confidence to merge it. Sadly most tags tests are pretty scrappy. __ALLWAYS__ a smaller PR is better is a good mantra :grin:. -- 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/2778#issuecomment-864631539
