Message ID | 20210215154427.32693-1-avarab@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | userdiff: refactor + test + doc + misc improvements | expand |
On Mon, Feb 15, 2021 at 10:44 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > Incorporates all the feedback on v2 and more, see the range-diff > below. I hadn't finished reading the previous version of this series... Nevertheless, see a few issues below which I noticed while scanning the range-diff... > ++expect to appear in the hunk header. We munged away the starting "@@ > ++[...] @@" part of the line for ease of not having to hardcode the line > ++numbers and offsets. Nit: "munge" is an oddball word to use here. "We strip away the starting..." would be simpler, but perhaps it doesn't matter too much as this documentation is aimed at developers, not end users. > ++For built-in patterns, you do not need `diff.<lang>.xfuncname` in your > ++configuration file as discussed above, but if present, it will > ++override a built-in pattern. > + > -+You still need to enable built-in patterns with the the attribute > -+mechanism, via `.gitattributes`). > ++Nevertheless, you need to enable built-in patterns via .gitattributes` > ++for the pattern to take effect. Missing opening backtick on `.gitattributes`. > ++Patterns in in a list of multiple that begin with "!" are negated. A > ++matching negated pattern will cause the matched line to be > ++skipped. Use it to skip a later pattern that would otherwise match. It > ++is an error if one or more negated patterns aren't followed by a > ++non-negated pattern. s/in in/in/ Also, "of multiple" what? > ++To match a literal "!" at the start of a line, use some other regex > ++construct that will match a literal "!" without "!" being the first > ++character on that line, such as "[!]". Overall, I find this description easier to read and understand than in the previous version.
Am 15.02.21 um 16:44 schrieb Ævar Arnfjörð Bjarmason: > Incorporates all the feedback on v2 and more, see the range-diff > below. I've read through all patches and left a few comments. My main critique is that the new way to specify test cases is not an improvement because the code is hard to parse. The desire to improve test precision moves the balance too far away from the simplicity to add new test cases, IMO. I appreciate the new test cases for ADA and Ruby as well as the discovery and fixes of the many small deficiencies. -- Hannes