So I was looking at this vim tip for finding in files from within Vim – while it looks helpful, there are a number of possible improvements:
- Why a static binding? being able to tweak the patterns or the files to search is quite common – so much more value if you could have the command printed in the command line, ready to be edited to your heart’s content or just go ahead and execute the search with
- The tip wont work for files without extensions (say .vimrc) – in this case,
expand("%:e") returns empty string
lvimgrep is cross platform but slow – let’s use Mingw grep too for
- And make that Mingw grep integration work on different machines
It was more of an evening of scratching an itch (a painful one if you’re zero in vimscript ). Here’s the gist gist for it- hope someone finds it useful.
Feel free to tweak the mappings – I use the following:
- leader-f: normal mode: vimgrep for current word, visual mode: search for current selection
- leader-fd: Similar – but look in the directory of the file and below
- leader-*: Similar to the above, but use internal grep
Save the file to your .vim folder and source it from .vimrc
A few notes:
- GNUWIN is an env variable pointing to some folder where you’ve extracted mingw findutils and grep and dependencies
- The searches by default work down from whatever vim thinks is your present working directory. I highly recommend vim-rooter if you’re using anything like subversion, mercurial or git as vim-rooter automatically looks for a parent folder that contains .git, .hg or .svn (and more – please look it up)
Here’s how it looks in action when I’ve selected some text and pressed leader-f:
Vim installed by Cygwin’s setup project does not have Ruby/Python/Perl support enabled by default. As my list of must have vim plugins has a few which use Ruby and Python, thought that it might be good to build my own Cygwin build of Vim. Turned out a little more work than I thought – but that’s more due to the misleading (at least for me ) Make file in the vim source tree called Make_cyg.mak.
Here’s how to compile:
- Make sure you have python (and ruby, perl and whatever other interpreters you need vim built with) installed.
- Do not install vim through cygwin (or uninstall it if you have it)
- Download vim source tarball, untar it and go into the
./configure --enable-pythoninterp --enable-perlinterp --enable-rubyinterp --enable-gui=no --without-x --enable-multibyte --prefix=/usr
make && make install
- You’re off to the races!
Ultisnips has been updated to 2.0. See the video here for the updates and new features. One piece of information – and one that I was eagerly waiting for is that 2.0 works perfectly with auto complete popup. This wasn’t always the case – in fact, the bug on launchpad for the same had been marked as a ‘wont-fix’. In any case, I was super thrilled to see that its been fixed.
Zencoding.vim also has been updated… if you’re writing any sort of markup the old way, then just google zencoding – there’s a couple of videos that will blow your socks off. For the truly impatient, you write a CSS like expression and its converted back to markup! How cool is that?
So my affair with Vim continues – and I seem to have discovered VIM’s macro super powers. The obvious next step is to shout from the rooftops and hence this blog post (and there’s hardly anything original – apart from the fact that I’ve just had a ‘aha’ moment when it comes to macros and thought it might help other budding vimmers out there…
A little primer – Macros let you repeat a set of commands. The way to go about it is to press
<macro_letter> is between lowercase a-z. This starts recording a macro in Vim (and you see a
recording message at the bottom). Now hit commands you want to repeat later and press
q when done to finish recording. VIM records all the keystrokes you enter in the register you specified as the macro name. To now execute the macro, position the macro on the line and then hit
@<macro_letter> and Vim will faithfully replay your commands.
Its a great time saver – especially for complex editing tasks where search/replace doesn’t cut it. But, if you’re feeling a dissappointed after coming this far (after all, I promised a aha moment), then hang on.
Today’s discovery was that you can edit macros that you’ve recorded quite easily and save them back!!! THIS IS HUGE. Why so? Because when you record a macro, its quite normal to jump around quite a bit or get one or two keystrokes wrong. In fact, its for this reason that I could never use Emacs’s macro facility and failed to just ‘get it’. However, in VIM, you could just open a scratch pad editor and hit
"<macro_letter>p – that’s double quote-letter-p to paste the contents of register containing your macro. You see your macro keystrokes – so go ahead and edit them and then use
"<register>y<movement> to save your edits back to the register. You can now execute the macro with a
@<macro_letter> as if that’s the way it was recorded in the first place.
Another obvious tip – you can
execute the contents of any register as if it were a macro with a @. Not sure when that could be helpful – but knowing that its possible is good.
Now that I feel quite comfy with VIM, over the weekend I needed to edit a config file in my Ubuntu 10.10 Virtualbox machine quickly. Instead of GVim, I just opened the file in console VIM. As I hit i to get into insert mode, a bunch of weird character boxes were inserted. That was not good at all – just when you think you’re comfortable with something if it does something totally weird. In any case, I was in too much of a hurry to bother and went about editing my file with gVim. Also, backspace was wonky (same weird characters) – so I felt better. For some reason that I fail to understand, why must Linux make proper backspace and delete handling such a pain! In any case, it’s something that I’ve dealt with enough times to know that there’ll be something on Google.
Later on, tried to see what all the fuss was about. Googling around, I found
:help :fixdel and that seemed simple enough. Alas, when I tried it out, it didn’t fix the issue at all. Also, I seemed to be getting weird characters just pressing
i to get into insert mode – and the VIM wiki page didn’t have anything about that. Neither did Google turn up anything that seemed related.
So today early morning, on a whim, read up a little on VIm terminal handling. I have the following in my .vimrc
Maybe it was the color escape code that was coming in – so checked out
:echoe &term which returned
xterm under gnome-console and
builtin_gui under gvim. So I’ve put the following bit in my .vimrc and it seems to have fixed things nicely:
if &term == "xterm"
So I had the bright idea (by no means original, though, as I later figured out) that it’d be great to avoid the Esc key on Vim as its so far away from the home row. The alternative to pressing
Ctrl-[ which, even though I’ve mapped CapsLock to control, I still find hard. So then, after some more googling around I’ve settled down on mapping
Esc. Its been a few hours with this setup and while its been an absolute pain till now, I think its a great way to avoid the Esc key jump. I can already feel my finger muscle memory relearning and my hand jumps instinctively for the Esc key much less now.
Here’s my setup in case you want to try this out. Bung the following into your
_vimrc as the case may be:
inoremap :echoe "use jk"
The first mapping makes VIM echo a reminder. Its not friendly since it introduces a pause. However, the idea is to make the Esc so painful that you will shy away from hitting it.
Is it worth it?
Definitely seems to be. I’ve looked at VIM in the past, tried it out too a couple of times or more, failed miserably(mostly within a day or two) and then wondered Why nutheads use VI. This would usually be followed with going back to the comfort of Emacs. I think over the years, I’ve spent more time customizing Emacs than actually getting any work done with it. And somewherethat felt wrong. In light of that, the minimalistic VIM looked attractive and worth another try.
So what about this time?
So this time things worked out a bit better. Rather than firing up VIM, spent some time reading through other’s experiences on picking up VIM. And the first thing I did right was to disable the arrow keys in normal mode (I still have them in insert mode)
" disable arrow keys
noremap <Up> <NOP>
noremap <Down> <NOP>
noremap <Left> <NOP>
noremap <Right> <NOP>
Once you have that bit, you’re forced to use h/j/k/l. And while h/j/k/l muscle memory is built up within a week, the nice thingthat really happens is that you dont use h/j/k/l much – instead you move to using more efficient movement commands. There’re aton of resources/cheatsheets on the web – but the approach I followed was to figure out some small keystroke when I needed it.What that mean’t was that I could get work done – but at the same time get more efficient gradually.
VIM out of the box is pretty badly configured – and that’s part of the reason that people seem to shy away from it. In fact, all the times that I tried out VIM before, I didnt even come close to cusotimizing my .vim. There are folks who have curated vim dotfiles on github etc – but my advice is to stay away from them. You should know what goes in your .vim and be in control of thatrather than getting a bunch of things in your .vim that you dont understand. Just so you know, looking at the github history for my vimfiles repo – the initial commit was 3 months ago – but after that, all the commits have come in only in the last 4 weeks.What that means is that while I put in a vim file initially, I didnt do much with it initially since I was just getting a hang of the basics. Once one becomes comfortable with the basics, one moves to customizing the vim environment more and more.
To summarize, VIM definitely seems nice once you invest into it. It’s easy to drop off in the initial stage and not go any further – and I believe this is what happens to the vast majority of folks who try it out. However, once you build that initial comfort level,it feels light, fast and easy.Start easy, persist, and customize bit by bit – you’ll feel yourself going from struggling with Vim to feeling comfortableand then to customizing your environment for an even better experience with VIM.I’ve definitely been more productive with VIM than I ever felt I was with Emacs – and these posts to my blog from Vim part of that.Besides that, I’ve used VIM effectively with a decent sized js code, html markup etc and felt the speed of editing inspite of still beinga noob in Vim terms.
Running ubuntu 10.10 here and ubuntu repos have only vim 7.2. I’m sure there’s a ppa out there that has 7.3, but thought
that compiling vim from source would be a good exercise – plus I get to compile it with the options that I’d like
rather than relying on someone’s build.
Here’s the options that I enabled:
CONF_OPT_PERL = --enable-perlinterp=dynamic
CONF_OPT_PYTHON = --enable-pythoninterp
CONF_OPT_RUBY = --enable-rubyinterp
CONF_OPT_GUI = --enable-gui=gtk2
CONF_OPT_FEAT = --with-features=huge
BINDIR = /usr/bin
DATADIR = /usr/share
Here’s hte other dependencies I had to install
sudo apt-get install libperl-dev ruby-dev python-dev libgtk2.0-dev
Once you have the deps installed, just run
So now I’m in Vim land and this is the first time I’ve gotten far enough to feel a bit comfy. Decided to dust off my blog and start at it again – what better to do it in than in VIM.
So – TA-DA – here’s the first post – courtsey VIM on ubuntu. However, as usual, it was rougher than it’s supposed to be. IN any case, I’ll forget how I got this far the next time so the next few posts will be around recording how to get VIM to post to WP.com blogs.
But before that – the first thing to to is to get the VimRepress plugin. Better if you have pathogen installed, in which case you can do
git submodule add https://github.com/raghur/VimRepress bundle/VimRepress.git
That’s my fork on Github of https://github.com/connermcd/VimRepress.git which fixes a few things:
- Makes VimRepress work properly through a proxy
- Changes the attachment filename to a ‘.odt’ since WordPress.com doesn’t allow a text file attachment.
I still dont have a clue if doing this will break the plugin – but nevertheless, basic case of posting to my blog works and at this stage that seems good enough for me.
PS as you can see from this post – I’ve not yet got a hang of markdown syntax
Dec 29th – PPS a couple of posts and one more tip for WordPress.com. WP.com does
<br/> for hardbreaks in the markdown text. Obviously, this doesnt leave the post looking very good. I have the following in my .vimrc to get around this
autocmd FileType markdown set wrap
You will also need to have python markdown installed once you have VimRepress running.