[bug #62042] [man]: want designed, documented CHECKSTYLE feature

[G. Branden Robinson]

Update of bug #62042 (project groff):

                Severity:              3 - Normal => 1 - Wish               
                  Status:             In Progress => Postponed              
                 Summary: groff: CHECKSTYLE: (incorrect) warning about blank
lines inside .EX/.EE => [man]: want designed, documented CHECKSTYLE feature

    _______________________________________________________

Follow-up Comment #6:

[comment #5 comment #5:]
> What I'd like then, is to be able easily preclude some warnings.  I guess
it's possible, but would like you to confirm (and hopefully show an example). 
For example, for clang-tidy, I use:
> 
> $ cat etc/clang-tidy/config.yaml 
> ---
> Checks: >
>     *,
>     -altera-id-dependent-backward-branch,
>     -altera-unroll-loops,
>     -bugprone-narrowing-conversions,
>     -clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling,
>     -concurrency-mt-unsafe,
>     -cppcoreguidelines-avoid-magic-numbers,
>     -cppcoreguidelines-init-variables,
>     -cppcoreguidelines-narrowing-conversions,
>     -google-readability-braces-around-statements,
>     -hicpp-braces-around-statements,
>     -llvmlibc-restrict-system-libc-headers,
>     -misc-no-recursion,
>     -readability-braces-around-statements,
>     -readability-function-cognitive-complexity,
>     -readability-isolate-declaration,
>     -readability-magic-numbers,
> 
> WarningsAsErrors: >
>     *,
> ...
> 
> 
> Something similar in a <etc/groff/tmac/checkstyle_exceptions.tmac> would be
nice.  Since maybe there are other things in level3  (or a hypothetical
level4) that I do want.  My typical usage of warnings is:  set them all, and
then remove those that cause noise.

I completely understand and sympathize with your aims, here, and in general I
share them.  The only problem is that to attack the problem as you suggest
requires that thing I explicitly disclaimed the (undocumented) "CHECKSTYLE"
feature as missing:

*design*.

If I change CHECKSTYLE in the future such that there is something in else in
level 3 that you want, or introduce a level 4, then I reckon that will be the
time to roll up my sleeves and develop a proper design, with names for the
warning types, and (ugh) string parsing inside the macro package to set up
flags for the desired warnings.

But right now, that is a significant investment for no extant use case, so I
want to procrastinate it.  :)

I am very glad to hear that -rCHECKSTYLE=2 meets your current needs without
giving up anything that you want.  I will therefore change the summary of and
postpone this ticket until the dread day arrives when I must practice the art
of design. ;-)

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62042>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/