view release on metacpan or  search on metacpan

lib/Devel/PerlySense.pm  view on Meta::CPAN

recursively used modules (which is perfectly fine Perl)

=back


Syntax errors and warnings both use the error face.

L<Perl::Critic> violations use the warning face.



=head3 Enabling Flymake

First off, flymake itself needs to be enabled. Refer to the Emacs
Installation description above.

This will enable Flymake for all cperl-mode buffers, causing Emacs to
call perly_sense for each check.

I<PerlySense won't do anything at this point though>. You still need
to configure what should happen during a flymake.

Create a PerlySense Project directory (see below) and look in the
project.yml file for instructions on how to configure Flymake
activities.

Set "syntax" and/or "critic" to 1 to enable them.

B<The primary reason "syntax" is turned off by default is that it's a
potential security hole>; running C<perl -c> on a file will not only
check the syntax; C<BEGIN> and C<CHECK> blocks are also
executed. Doing that on random code may be considered... baaad.

This way you can have Flymake enabled globally and still not run
C<perl -c> on everything that happens to be in a buffer.



=head3 Using Flymake

In the Project config file there are some hints on how to customize
Flymake, when it should run, etc. You can also customize it with C<M-x
customize-group flymake>.

(Personally I find the nagging while I type very distracting, but I
welcome the immediate feedback whenever I save the file. YMMV.)

Look in the mode line for hints on whether there are any errors or
warnings.

C<C-o s n> -- Go to the next Source error/warning.

Display the error in the minibuffer. If the warning is from a
Perl::Critic module, copy the module name into the kill-ring, so you
easily can yank it into the .perlcritic config file to disable
it. (not implemented)

C<C-o s p> -- Go to the previous Source error/warning.

C<C-o s s> -- Display the error/warning text of the current line in a
popup. Or display the error in the minibuffer if the display isn't
graphical, or if the ps/flymake-prefer-errors-in-minibuffer variable
is customized to a true value.



=head3 Code Coverage Visualization Introduction


=for html <p>[ <a href="http://search.cpan.org/src/JOHANL/Devel-PerlySense-0.0217/doc/code_coverage.html">Screenshot</a> ]<p>


If you have a test suite, you might like this. You should have tests.

If you run Devel::Cover, you'll be happy. You should know your code
coverage.

PerlySense can display the code coverage in the source buffer.

Currently supported is subroutine coverage, i.e. whether a sub is
covered by tests or not.

Covered subs are displayed with a discreet green underline, uncovered
subs get a red underline.




=head3 Coverage Visualization Setup

PerlySense uses L<Devel::CoverX::Covered> to manage the coverage
data. Refer to that documentation for how to run your test suite with
L<Devel::Cover> and generate a "covered" database.

The "covered" database should reside in your project root dir and
contain files with file names relative to the project root dir (that's
ordinarily the case).

Note: Running the test suite with Devel::Cover can be very, very
slow. A nightly build is usually a good idea.

You can also collect / undate coverage information for indivual test
files with C<C-o r c>. This is the easiest way to just try it out.

You might want to add the following to be ignored by your VCS
(e.g. .gitignore):

    /cover_db/*
    /covered/*



=head3 Using Coverage Visualization

You can toggle Visualization with C<C-o C-v> at any time when editing.

You can also enable Visualization by default in the install script
(see above), or via C<M-x customize-variable
ps/enable-test-coverage-visualization>.

Whenever Visualization is enabled, PerlySense will try to fetch