While bumping the editorconfig-checker pre-commit hook to v3.11.3 (#7459),
its newer binary-detection check started flagging four files as non-UTF-8
because they contain stray control bytes. I worked around it in .editorconfig
by marking those files charset = unset (see #7459), so the
editorconfig-checker no longer fails the build.
That's an adequate mechanical fix, but three of the four files raise a
judgment call worth a separate discussion:
raster/r.drain/READMEscripts/r.drain/READMElib/external/ccmath/C01-matrix
raster/r.drain/README and scripts/r.drain/README
Both are copies of the same 2001 email from Roger Miller to Markus Neteler,
kept as historical documentation of the tool's origin. Line 24 of each
contains a single stray 0x18 (CAN) control byte in the middle of a word:
that <CAN>differ a little from r.drain.
This isn't part of the original message's meaning, and is unlikely to be
intentional. It looks like a leftover encoding/transcription artifact from
whenever the email was pasted into the repo.
lib/external/ccmath/C01-matrix
Lines 880 and 881 each contain the same pair of stray control bytes, 0x13
(DC3) and 0x16 (SYN), embedded inside a variable name:
m = number of rows in the U<DC3>1<SYN> matrix
n = size of the d and e arrays, number of columns in the U<DC3>1<SYN>
Read past the control bytes, this is "U S1 V" -- almost certainly referring
to the U, S1, V matrices of a singular value decomposition (A = U S1 V^T),
which this file's SVD routine documentation is describing. The DC3/SYN pair
looks like a leftover formatting code (e.g. subscript/superscript toggle)
from whatever tool originally produced this vendored documentation, not
meaningful content.
Discussion
configure, the fourth flagged file (autoconf-generated, using a BEL byte
as an awk field separator), clearly should not be hand-edited. The other
three are different: they're vendored/historical text we've chosen to keep
verbatim, so there's a real question of whether to clean them up now that a
tool has flagged them.
Options:
- Leave them as-is (verbatim historical record, warts included) and keep
the .editorconfig exceptions.
- Strip the stray control bytes as a trivial, meaning-preserving cleanup,
and drop these files from the .editorconfig exception list.
Opening this for input since it touches how strictly we want to preserve
old, pasted-in text verbatim vs. tidying it once a tool happens to notice.
While bumping the editorconfig-checker pre-commit hook to v3.11.3 (#7459),
its newer binary-detection check started flagging four files as non-UTF-8
because they contain stray control bytes. I worked around it in .editorconfig
by marking those files
charset = unset(see #7459), so theeditorconfig-checker no longer fails the build.
That's an adequate mechanical fix, but three of the four files raise a
judgment call worth a separate discussion:
raster/r.drain/READMEscripts/r.drain/READMElib/external/ccmath/C01-matrixraster/r.drain/README and scripts/r.drain/README
Both are copies of the same 2001 email from Roger Miller to Markus Neteler,
kept as historical documentation of the tool's origin. Line 24 of each
contains a single stray
0x18(CAN) control byte in the middle of a word:This isn't part of the original message's meaning, and is unlikely to be
intentional. It looks like a leftover encoding/transcription artifact from
whenever the email was pasted into the repo.
lib/external/ccmath/C01-matrix
Lines 880 and 881 each contain the same pair of stray control bytes,
0x13(DC3) and
0x16(SYN), embedded inside a variable name:Read past the control bytes, this is "U S1 V" -- almost certainly referring
to the U, S1, V matrices of a singular value decomposition (A = U S1 V^T),
which this file's SVD routine documentation is describing. The DC3/SYN pair
looks like a leftover formatting code (e.g. subscript/superscript toggle)
from whatever tool originally produced this vendored documentation, not
meaningful content.
Discussion
configure, the fourth flagged file (autoconf-generated, using a BEL byteas an awk field separator), clearly should not be hand-edited. The other
three are different: they're vendored/historical text we've chosen to keep
verbatim, so there's a real question of whether to clean them up now that a
tool has flagged them.
Options:
the
.editorconfigexceptions.and drop these files from the
.editorconfigexception list.Opening this for input since it touches how strictly we want to preserve
old, pasted-in text verbatim vs. tidying it once a tool happens to notice.