Idea: Show name of violated rule + offer waiving button

[afgit]

perlcritic extension successfully shows what is wrong with the code. But sometimes it is desirable to keep the code as it is and just hide the warning. To accomplish this, perlcritic recognizes ## no critic (<rule(s)>) comments (see BENDING-THE-RULES)

Now, to insert such a comment, you need to know the name of the rule that you are violating. The extension elaborates on the rule itself, but unfortunately does not mention its name.

It would be very helpful to have the name of the rule available without having to google it in the first place. (Starting with verbosity of 8, perlcritic also outputs the rules' names)

Even more useful would be a button like "waive it" that automatically inserts a ## no critic ... comment at the end of the offending line. (Quick Fix would be wrong as it actually wouldn't fix the problem, just hide it)

[jesteves]

In addition to @afgit comment, maybe the extension should honor the verbose setting on the profile file (~/.perlcrticrc).

In my case I have it this way:

 #
 # verbose : custom format for violation explanation
 #   %m="brief description"; %l="line number"; %r="faulty source code";
 #   %e="explanation with reference to PBP"; %p="policy violated";
 #   %s="severity"; %d="full diagnosis"
 #
 verbose = %m at line %l, near '%r'.\n%e.\n(Policy: %p\tSeverity: %s)\n%d\n\n

which works perfectly fine [for me], showing the violated policy com command line:

Magic variable "$ENV" should be assigned as "local" at line [...], near '[...]'
See pages 81,82 of PBP.
(Policy: Variables::RequireLocalizedPunctuationVars     Severity: 4)
    Punctuation variables (and their English.pm equivalents) are global [...]

Maybe even just to have the name of the policy visible on VSCode console would be useful for copy/paste as a ## no critic rule.

[dseynhae]

Honoring the verbose statement in ~/.perlcriticrc is not as straightforward as it sounds: The Perlcritic extension parses the output of perlcritic, to create the diagnostics that we see inside VS Code. This can only be done if the output is in a known format, that has all the necessary information to make the "Problem" feature work.

Currently, the extension makes this work through --quiet and a --verbose on the command line when invoking the perlcritic "server" (which is basically a perlcritic instance that constantly listens to STDIN).

The server overwrites the verbose definition from the init file. (currently, it is something like:

verbose = %l[>]%c[>]%s[>]%m. %e (%p)[>]%d[[END]]

The syntax hooks for the parser are quite obvious, and necessary for the extension to work...

[dseynhae]

(Quick Fix would be wrong as it actually wouldn't fix the problem, just hide it) @afgit

I'm not sure why we couldn't use the "Fix It" mechanism to "waive" error messages. The pure intent of the "Fix It" mechanism is to propose an alternative, which make the DIAGNOSTIC go away. This is still the decision of the programmer, because the proposal might not be appropriate for the programmer's intent.

Adding a ## no critic (<rule>) pragma does exactly that! It makes the diagnostic go away upon approval of the programmer.

I think we need to live within the features as offered through the VS Code API. Bypassing this API to implement other desired features or functionality can only cause chaos between the many extensions?