Looks simple enough, should do some research to exactly how un-simple it will be.

If perl critic crashes, critique doesn't recover.

To reproduce, create a perl script that chokes perlcritic (e.g. use an unquoted non-ASCII key name in a hash):

#!/usr/bin/perl
use utf8;
my $foo = { fó => 3 };

perlcritic will choke:

$ perlcritic x.pl
Problem while critiquing "x.pl": Can't parse code: Fatal error... regex failed to match in 'ó => 3 };
' when expected at /usr/share/perl5/PPI/Token/Word.pm line 217.

And when critique comes across such an error, it doesn't recover:

Running Perl::Critic against ([path hidden])
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Can't parse code: Fatal error... regex failed to match in 'ú}->{mappings}}), 2;
' when expected at /usr/share/perl5/PPI/Token/Word.pm line 217.

Plugins look pretty simple, should likely do this and save some method calls

https://metacpan.org/source/RJBS/App-Cmd-Plugin-Prompt-1.005/lib/App/Cmd/Plugin/Prompt.pm

The output should be able to be internationalized, which should be relatively straightforward using something like Locale::Maketext.

This would populate the values in %App::Critique::CONFIG, which are currently being populated in the bin/critique script.

Additionally we need to add support for the %SKIP values in App::Critique::Command::collect to this config (see comment on #9 for more info)

This would put the .critique directory into the current working directory, this would allow you to keep project local critique session files.

NOTE:
To avoid different users overwriting each others session files, the repo-name portion of the .critique path should be replaced by $USER or the git users email.

$subject

Some editors do automatic text formatting (especially as it relates to whitespace), or one may patch up some related code while fixing a perlcritic issue.

In such cases, the ability to run git add -p could be invaluable in separating the perlcritic-related fixes from other changes.

Commit Message:

    Variable declared in conditional statement - critique(Variables::ProhibitConditionalDeclarations)

Choose (y)es to use this message, or (n)o for more options [Y/n]: n
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
What would you like to edit? (f)ile, (c)ommit message: 

Perhaps this prompt could add a (p)atch option to select which changes are included in the commit.

Basically you get the same thing as status does, but instead of a file list you get git show for each sha associated with the file.

When using a graphical editor (atom in my case) which automatically drops to the background, critique re-scans the target file before an edit has been made:

Would you like to fix this violation? [Y/n]: 
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
No edits found, would like to (e)dit again, or (s)kip this file?: 

My present work-around is to select 'e', which re-launches the editor before re-scanning the file. I suggest adding a (r)e-scan option, to skip the editor launch before re-checking for changes.

On a large repos it can take a little while sometimes to start up and load the session file, this can be short circuited by just checking for the file and only then loading the session.

Found 2 violations, would you like to review them? [Y/n]: 

I'd like to see this prompt changed perhaps to:

Found 2 violations, would you like to review them? [Y/n] or open in (e)ditor: 

As discussed in #22 we should show +/- 5 lines of source around the actual violation when reviewing them. Maybe even make the number of +/- lines a configuration variable.

When I updated my git checkout, some files and directories were removed. Now critique dies when it comes to them, and I find no option to skip:

=============================================================================================================================================================================================================================================
Running Perl::Critic against (apps/oozie/workflows/ranking-nbl-v2/export.pl)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Can't parse code: Did not pass a PPI::Tokenizer object to PPI::Lexer::lex_tokenizer

Path::Class and File::Spec are great, but Path::Tiny seems more sensible and I need to just make the switch in my brain.

What would you like to edit? (f)ile, (c)ommit message: c
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Please write a commit message: : 

It might be nice to show the original commit message as the default. Or better, perhaps, open the commit message in an editor, with the default in place (i.e. git commit -e -F)

Git::Wrapper disables ANSI color output from git by default, but enabling this for diffs could be handy.

The ~/.critique directory can get cluttered, so we should write some commands that manage it, such as:

• traverse subdirectories and figure out all the open sessions
• clean up old sessions
• etc.