Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Test driven development with Perl and vim

by dragonchild (Archbishop)
on Feb 28, 2005 at 19:25 UTC ( #435163=note: print w/ replies, xml ) Need Help??


in reply to Test driven development with Perl and vim

In your .exrc file, add the following lines:

autocmd BufNewFile,BufRead *.p? compiler perl autocmd BufNewFile,BufRead *.p? map v :make^M autocmd BufNewFile,BufRead *.p? so ~/perltest.vim autocmd BufNewFile,BufRead *.t compiler perl autocmd BufNewFile,BufRead *.t map v :make^M autocmd BufNewFile,BufRead *.t so ~/perltest.vim

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.


Comment on Re: Test driven development with Perl and vim
Download Code
Re^2: Test driven development with Perl and vim
by gaal (Parson) on Feb 28, 2005 at 20:17 UTC
    What does :make buy you here? vim's makeprg just automates loading the error file, but that's taken care of in the Prove function. If you're going into the trouble of using make IMHO you may as well leave it for c development so that if you're writing a module with XS in it you get quickfix benefits for that.

    Did you figure out that CompilerSet business going on in compiler/perl.vim? Maybe that's the key to localizing settigns that will help develop with more than one language at a time.

      Actually, as I discovered after posting, it's a lot easier to write a Compile() function that you get to control (like adding -Ilib) than depending on vim's make. So, I took that out. Plus, I found a few things better than BufNewFile and BufRead.

      This is how my .exrc snippet looks now:

      autocmd BufNewFile,BufRead *.p? so ~/.vim/perltest.vim autocmd BufEnter *.p? colors peachpuff autocmd BufNewFile,BufRead *.t so ~/.vim/perltest.vim autocmd BufEnter *.t colors blue

      And, I make a few changes to my perltest.vim

      The main changes are:

      • Addition of ,T allowing for make test TEST_VERBOSE=1
      • Addition of ,v allowing for compile of .t files. This entailed creating Compile()
      • Addition of -l flag to prove, keeping the vim editor in the same directory as the tags file.

      I'm still figuring out the various parameters. Heck, I've learned more about the vim settings in the last hour than I had in the 10+ years I've been using vi-based editors! :-)

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        Good point about taint mode. And -l can't hurt either, so I'm adding it too, though in all my new projects I've stopped with the (h2xs-originated, I think) legacy of putting everything under lib/. Well, actually if it's a web project I *do* use lib/ (and htdocs/ etc); but otherwise it's just snappier to use the main directory as the root for libraries.

        I'm not sure why you need the separate binding for compilation at all? I actually see it as a feature that Prove() does the Right Thing depending on whether the file is a test or not. (After all, if your test fails compile, quickfix will put you in the right place even if the compilation error happened when you tried to run the test.) Think of it as polymorphism at keybinding time :)

        Thanks for the comments!

        Update: Interesting thinko on my part, taking "verbose" for "taint". Well, I suppose they both tend to produce mode output than the regular checks :) I'm not convinced a verbose launch deserves a keybinding of its own — how often do you alternate? — maybe it's better to make both taint and verbose modes global options and keep the keys simple.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://435163]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2014-10-25 08:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (142 votes), past polls