What cool stuff are y'all doing with Vim and Perl and how can we get the rest of the programmer public to take advantage of those marvelous advances you're using?
On Thursday 04 June 2009 01:21:40 Andy Lester wrote:
> Wow, 40 subscribers in 18 hours. Not bad.
> What cool stuff are y'all doing with Vim and Perl and how can we get
> the rest of the programmer public to take advantage of those marvelous
> advances you're using?
Hi!
I'm doing most of my programming (and text editing in general) in Vim, and that includes Perl programming. Most of the vim functionality I've been using is programming language-neutral, and I've been blogging about various tips I've discovered here:
I'm using the perl-support vim plug-in, which has some nice features, but can also be annoying. For example, when I type "\@" in insert-mode, it insert a weird "my @..." declaration. Turns out that after typing \ one has to wait a little before being able to continue because the perl-support bounded that key. I also did not get used to using the perl-support code generation feature, and I noticed that in a way, it was not adapted for more serious code. For example when generating a function it does:
I no longer use the xmms play and enqueue. The perl-test-manage.vim is now mostly implemented using Test::Count (and thus I need to release a new version of it.). range-search.vim is still relevant and I'm still using it.
On Jun 4, 7:55 am, Shlomi Fish <shlo...@iglu.org.il> wrote:
> I'm using the perl-support vim plug-in, which has some nice features, but can
> also be annoying. For example, when I type "\@" in insert-mode, it insert a
> weird "my @..." declaration. Turns out that after typing \ one has to wait a
> little before being able to continue because the perl-support bounded that
> key.
I have to admit, that feature has driven me nuts. I remember
attempting to find a setting to disable or change the key it was using
for the trigger but I wasn't able to. I'm sure it is somewhere in
there.
> I also did not get used to using the perl-support code generation
> feature, and I noticed that in a way, it was not adapted for more serious
> code. For example when generating a function it does:
There is a code snippets directory in the ~/.vim folder that should
have the template it uses to generate that code. Should be just a
matter of editing it as you see fit.
Myself, I primarily find tabs and sub folding to be my favorites. I
still haven't found an out-liner window that I like. The tabbing
support was incredibly annoying to get right. As I use PuTTY and I
wanted to sent C-S-TAB and C-TAB as my tabbing keys. PuTTY doesn't
send CTRL key-bindings. That was an interesting endeavour.
As I usually work out of a project's root directory for editing its
files, I commonly have to build/install it to test it (most of the
projects are web-based). For this I use the following map:
"save buffer and build
:inoremap <Esc>b <Esc>:w<CR>:! ([ -e Build.PL ] && ./Build install) \|
\| ([ -e Makefile.PL ] && make install )<CR>i
:nnoremap <Esc>b :w<CR>:! ([ -e Build.PL ] && ./Build install) \|\|
([ -e Makefile.PL ] && make install )<CR>
Saves the buffer, checks if we are using a Build.PL based installer,
install or if we are using Makefile.PL, install using that.
And of course perltidy. Who doesn't like perltidy?
"Tidy block
vnoremap <silent> t :! perltidy -q<CR>
"Tidy entire file
nnoremap <Esc>t :%! perltidy -q<CR>
Those are some of the things that popped into mind, I'm sure theres
others. And probably cooler other things.
--
Danny.
The mind of the believer stagnates. It fails to grow outward into an
unlimited, infinite universe.
-Frank Herbert
> What cool stuff are y'all doing with Vim and Perl and how can we get > the rest of the programmer public to take advantage of those marvelous > advances you're using?
I generally assume that my use of Vim is far from state of the art. I don't look over other users' shoulders often enough to pick up juicy tips. But here's what I do:
I have my home directory in svn[1] and check it out on MacOS, Linux, Solaris, *BSD and Cygwin - so I try to keep my customisations as cross platform as possible. If you follow the link to the svn repo below you'll notice, for example, that my .gvimrc has all sorts of tweaks so that I get the same font size in MacVim and GVim.
I generally run console Vim and usually have multiple windows open in Vim[2] so one of my biggest time savers is:
They bind Ctrl+Left/Right/Up/Down to switch to the window in that direction and maximise it.
For every language for which I can find a decent source code prettifier I have a binding F2 -> tidy source. For Perl that's Perl::Tidy of course. I don't format anything manually if I can help it and using languages for which there is no prettifier has become a major pain as a result.
I have hooks so that when I create a new .pm file it attempts to guess the package name from the path and gives me a boilerplate module with the name filled in.
I have F5 bound to this script[3]. If the cursor is in a string literal it cycles the quoting between single and double quotes (and backwacks any embedded quotes to suit). If the string happens to be a valid bareword it also cycles through unquoted - and if the cursor is outside a string but on a valid bareword it will be quoted.
So I can
"foo" => bar # cursor in "foo", F5 'foo' => bar # F5 again foo => bar # F5 again "foo" => bar
I just started playing with that. The philosophy behind it is slightly more grandiose than that example suggests. I wanted to have a FIX THIS! key which I can hit whenever something doesn't look quite right and have it, based on context, cycle through a number of alternative representations. For example if the cursor is on 'for' or 'foreach' hitting F5 should cycle through those alternatives, Similarly if/ unless, while/until, &&/and, ||/or.
One of the criteria for success will be whether I start instinctively stabbing frantically at F5 when confronted with anything I don't like - even if it's not written in Perl and has no chance of working :)
There's other stuff - most of which can be gleaned from [1].
Incidentally I suspect my Vim coding style is painfully naive - criticism is welcome :)
On Thu, 2009-06-04 at 18:25 +0100, Andy Armstrong wrote: > On 3 Jun 2009, at 23:21, Andy Lester wrote: > > What cool stuff are y'all doing with Vim and Perl and how can we get > > the rest of the programmer public to take advantage of those marvelous > > advances you're using?
> I generally assume that my use of Vim is far from state of the art. I > don't look over other users' shoulders often enough to pick up juicy > tips. But here's what I do:
> I have my home directory in svn[1] and check it out on MacOS, Linux, > Solaris, *BSD and Cygwin - so I try to keep my customisations as cross > platform as possible. If you follow the link to the svn repo below > you'll notice, for example, that my .gvimrc has all sorts of tweaks so > that I get the same font size in MacVim and GVim.
> I generally run console Vim and usually have multiple windows open in > Vim[2] so one of my biggest time savers is:
> They bind Ctrl+Left/Right/Up/Down to switch to the window in that > direction and maximise it.
> For every language for which I can find a decent source code > prettifier I have a binding F2 -> tidy source. For Perl that's > Perl::Tidy of course. I don't format anything manually if I can help > it and using languages for which there is no prettifier has become a > major pain as a result.
> I have hooks so that when I create a new .pm file it attempts to guess > the package name from the path and gives me a boilerplate module with > the name filled in.
> I have F5 bound to this script[3]. If the cursor is in a string > literal it cycles the quoting between single and double quotes (and > backwacks any embedded quotes to suit). If the string happens to be a > valid bareword it also cycles through unquoted - and if the cursor is > outside a string but on a valid bareword it will be quoted.
> So I can
> "foo" => bar # cursor in "foo", F5 > 'foo' => bar # F5 again > foo => bar # F5 again > "foo" => bar
> I just started playing with that. The philosophy behind it is slightly > more grandiose than that example suggests. I wanted to have a FIX > THIS! key which I can hit whenever something doesn't look quite right > and have it, based on context, cycle through a number of alternative > representations. For example if the cursor is on 'for' or 'foreach' > hitting F5 should cycle through those alternatives, Similarly if/ > unless, while/until, &&/and, ||/or.
> One of the criteria for success will be whether I start instinctively > stabbing frantically at F5 when confronted with anything I don't like > - even if it's not written in Perl and has no chance of working :)
> There's other stuff - most of which can be gleaned from [1].
> Incidentally I suspect my Vim coding style is painfully naive - > criticism is welcome :)
On Thu, Jun 4, 2009 at 4:55 AM, Shlomi Fish<shlo...@iglu.org.il> wrote: > I'm using the perl-support vim plug-in, which has some nice features, but can > also be annoying. For example, when I type "\@" in insert-mode, it insert a > weird "my @..." declaration. Turns out that after typing \ one has to wait a
You should be able to unset that mapping by adding the following to your .vimrc file (or better yet ~/.vim/ftplugin/perl.vim):
unimap \@
The only potential problem I see is making sure that this is run after the perl-support plug-in is loaded.
On Fri, Jun 5, 2009 at 4:14 AM, Luke Triantafyllidis<ltri...@cpan.org> wrote:
> I use this key mapping to check the syntax of the current file I'm > editing.
> map ,pc <Esc>:! perl -c %<CR>
> Would be nice if I could get it to output to a separate buffer, but my > vim script-fu isn't up there yet :)
I'm not sure how to open the output in another window, but if you set "perl -c" as your compiler you can use the :make command to check syntax and then use :cn and :cp to move forward and back to each error. Here are the key lines from the rc files:
I actually use Christian Robinson's perl.vim compiler file which is a bit more complete (google for "Christian J. Robinson perl.vim" and save it as ~/.vim/compiler/perl.vim).
