Vim is actually quite easy to build from source with a
make install. You can edit
src/Makefileto enable features and custom language extensions. Turns out, I hadn’t scrolled through that file in a while, since version 8.0.1295 comes with an interesting addition – the compilation flag
Running the editor with a
--servernameparameter allows remote connections from a different instance using command-line flags or function calls. I’ve been using this functionality to build a custom testing framework in Ruby, but you have to knowingly launch it with that flag. Now, each instance can be available to connect with by default.
It’s not necessary, exactly – you could always make yourself a shell alias like
alias vim="vim --servername VIM-$RANDOM". But the discovery gave me an idea of how to remove a tiny bit of friction from my Rust workflow, and I might end up using the same technique in the future. Read on to learn how to send your build output to a Vim instance for easier processing.
There’s a little-known Vim command called
:TOhtmlthat does something quite surprising for a built-in – it converts the current Vim window into raw HTML. This includes syntax highlighting for code, and even line numbers. It can convert the full buffer or a range of selected lines.
While I’ve always considered it a fun trick, it was somewhat recently that I realized it has a very practical use – to paste syntax-highlighted code into presentation slides.
I recently started working with ember.js. It’s a nice framework, but, like most newish technologies, Vim support is minimal. So, as I usually do in such cases, I started working on some tools to help me out with navigation. Tim Pope’s projectionist helped a lot, but I wanted more, so I started building it up in what would later be published as ember_tools.
The biggest feature was the
gfmapping (“go to file”), which was inspired by the one in vim-rails. Using
gfin a rails project almost always does “the right thing” for whatever you can think of. So, I poked around in that one, tried to figure out how it was implemented. In the process, I learned a few things and had a bunch of pretty good ideas, which I’ll talk about in this blog post.
I went to OHM (Observe, Hack, Make) this year, a hacker festival in the Netherlands. It was a fun week of camping, freedom talks, technology, retro-gaming and all sorts of other cool stuff. Since I was going there anyway, I decided to make a Vim event to spread word of the One True Editor.
At the November Vimberlin meetup, I talked about my exprience of building a plugin, what decisions I made and what lessons I took away from it all. My hope was that the attendees could use my ideas in their own code, and maybe become motivated to get coding themselves. Here’s a short summary of the basic ideas I presented.
This year, I did a talk at OpenFest about Vim. I tried to make a few interesting points about Vim and why it’s awesome. In the end, it turned out to have too much talk and not enough mind-blowing plugin demos, which I should probably work on for next time.
For now, I’d like to quickly go over the three main points that I hope people took away from the talk. The slides are uploaded to speakerdeck, though they’re almost certainly useless without the demos and my explanations (not to mention they’re in Bulgarian).
In coffeescript, particularly when you’re dealing with nodejs, code is often wrapped with lots and lots of callbacks. Since the indentation of the wrapping function calls varies, it’s not very easy to move them around, delete them, or add new ones, because you need to adjust the indentation of the blocks of code they contain.
In my previous post, I defined two mappings to operate on blocks of code. In this one, I’ll define two that deal with the wrapping callbacks.
I recently started to write a lot of coffeescript at work, so I bumped into an issue that I’ve been avoiding for some time: manipulating indent-based languages. Theoretically, it should be easier (no “ends” or closing braces, right?), but I have a lot of tools to move code around, wrap it in blocks, or view it nicely, that just don’t work with semantic indentation. So, I had to experiment to come up with some vimscript to make it more comfortable. It’s all a work in progress, but it’s been rather useful for me so far.
Originally, I intended to write a single post, but I started off rather verbosely, so I decided to make it a series instead and explain the code in more detail along the way. To begin with, I’ll describe the process of writing two simple text objects that might be useful in day-to-day coffeescript development.
If you’re unfamiliar with text objects in Vim, you could get a good explanation from the help files with :help text-objects. Another nice introduction is Chapter 15 from “Learn Vimscript the Hard Way” by Steve Losh. It’s rather short, so I recommend you skip through it in any case.
For quite a while, the NERDTree has had some simple scripting capabilities. At some point, I decided to use these to override the basic filesystem menu it provides to something a bit weirder. My problem with the default menu was its lack of vim keybindings. Being in command mode is usually not an issue, since it’s fairly rare, but I got really used to moving and renaming files through the tree, so it was time to improve the experience a bit.
One of the more exotic features of Vim is its remote control functionality. Basically, if you invoke Vim with
--servername SOME_NAME, you’ll be able to send commands to it with another Vim instance. Using this, I’ve recently attempted to fix a common annoyance with vimscript – its limited testability. By spawning a remote instance and controlling it through ruby code, we can use cucumber to perform simple integration testing for Vim plugins.
This is not something I’d do for all code I write, but in some cases, it could be a life-saver. My splitjoin plugin is one example of a project that I wish I had a good test suite on, considering the amount of regressions I’ve had when modifying functionality. In this blog post, I’ll describe some ruby code to drive a Vim instance remotely and a few sample cucumber steps you could write to make use of it.
A while back, I posted an article on setting up Vim with ctags. In this post, I’ll go through the code of a small vim plugin I’ve recently published, tagfinder.vim, which is a generalization of the last example from that article. Basically, it lets you define custom commands to look for tags by their name, filtering them by a specific type – class, method, module, and so on. This doesn’t add a whole lot of value over the built-in
:tagcommand, but I find it’s still pretty useful. The idea was originally taken from Tom Link’s tlib library.
My goal is to show an example of moving from an idea of useful functionality to working vimscript. I am cheating quite a lot, since it’s something I’ve had in my vimfiles for a while now. I’ve only isolated it into a plugin, removing the dependencies and adding hooks for custom commands. This means that I have a good idea of what I want to do, so I’ll skip lots of steps in the process of describing it. Still, I think it might be useful to see the components of a simple vim plugin and how they work together. I’ll make a summary after the post with what I consider some of the more important lessons.
Pretty much all editors have the option of changing themes and tweaking colors. Vim’s no different, but instead of menus and wizards, it’s done by using vimscript. While it could be argued that this is more difficult than in a “conventional” editor, I really don’t think that’s the case. I’ve recently been hacking on my own color scheme a bit, so I’ll take this opportunity to do a post on how to manage colors in vim and achieve some nice effects.
Ctags is an old tool, just like vim, and it works wonders for code navigation. Since I was recently told that TextMate doesn’t have ctags integration out of the box, I figured I’d make an article explaining it. Even if you’ve used it before, I’ll describe some of my own workflow, so you might learn something interesting anyway. I’ll start from the basic usage, and then I’ll discuss things like keeping the tags file up to date and maintaining tags for any libraries you might be using.
Finding and replacing strings are often-used operations when editing text and vim has a full-featured regex engine to aid in that. Unfortunately, it’s one of a kind – neither POSIX- nor perl-compatible, though mostly the latter. There are various differences with perl, though, and minor oddities that can be pretty annoying until you get used to them, so I’ll try to explain a few of them here.
Note: I’ll be assuming you’ve worked with some flavor of PCRE before.
To start off, I’ll write about something I’ve actually seen interest in from people I know – my Vim configuration. I’ll try to explain my personal workflow and maybe share some useful tricks along the way. For now, I’ll limit myself to the basic stuff and exclude plugin-related wizardry, maybe I can devote another blog post to some of the plugins I can’t live without.