Mon 24 Oct 2016 10:45:11 AM UTC, comment #1:
It's been almost 3 years since a proposal was submitted on the mailing list:
http://lists.nongnu.org/archive/html/quilt-dev/2014-02/msg00050.html
It was reviewed a few months later (sorry for being slow):
http://lists.nongnu.org/archive/html/quilt-dev/2014-06/msg00014.html
There has never been any follow-up nor resubmission. Apparently the interest in this is pretty low.
Thinking about it again, I am not convinced this feature is actually desirable. Firstly, completion is not critical, it's only a bonus. Nothing really bad can happen from it being broken (as opposed to quilt itself, where a bug could cause real trouble.)
Secondly, testing coverage by humans is probably reasonably good in this area. I don't think there are so many corner cases. Also no dependencies on external tools which can behave in unexpected ways. So I would expect any problem with completion to be noticed and reported quickly by human users.
Thirdly, the most frequent change which affects completion is new options being added, or (less frequently) new commands being added. Existing test cases can't cover this by definition. Changes to existing options, even by accident, should be fairly rare, so the test cases are unlikely to catch any regression (which I consider the most valuable feature of a test suite, especially for a tool like quilt.)
Lastly, whenever we add a new option, the bash completion script should be updated accordingly. But the existing test cases will not fail if this is not done. OTOH they may fail if it is done, because then the completion output may change (new option being proposed.) This pretty much voids the point of having test cases. The main problem with the bash completion script is that it may not match the current set of commands and options implemented in quilt. But testing the completion itself does not help with this.
Therefore my conclusion is that this is more work than is worth, and I would rather not implement it.
|