Jon Bernard

Get More Out of Vim's makeprg

2011-09-30T00:00:00-04:00

This started out as a small post on how to preview markdown documents in Vim using makeprg, but somehow I got carried away. More on the markdown thing in a bit.

When you type :make in Vim, the value of makeprg is executed in a subprocess. Traditionally this value is set to make, but you can set this to anything you like. You can see the current value by typing :set makeprg. When you combine this with Vim’s support for filetype plugins, there’s a decent amount of value that I think is sometimes overlooked. So this article is an attempt to explain some of the things you can do with makeprg and filetype detection.

Filetype Plugins

A filetype plugin is like a global plugin, except that it sets options and defines mappings for the current buffer only.

Using a filetype plugin, we can set makeprg to something useful depending on the type of a file it happens to be. Adding your own filetype plugin is easy, just create a file of the form: <filetype>.vim inside the ~/.vim/after/ftplugin directory. The after subdirectory is technically optional, but I prefer it as it keeps things isolated from other installed plugins. The after subdirectory is sourced last as Vim initializes itself, so putting your options there ensures they aren’t clobbered by other plugins.

For a given Vim buffer, you can see the filetype by typing :set ft. Some people put this information in their statusline, which can be helpful if you’re writing Vim plugins or just want to make sure things are being detected correctly.

For example, if I want to define custom settings for the C filetype, I would create ~/.vim/after/ftplugin/c.vim and put my settings there. Any time a file of type C is loaded, my settings are applied. We can use this mechanism to set a custom makeprg for certain filetypes.

Customizing makeprg for Markdown

I take all of my notes in Markdown, which is nearly plain text with a tiny amount of markup. This allows me to quickly convert my personal notes into decent looking html documentation. It seems to be a regular occurrence that my notes become the initial documentation for the project or subproject that I’m working on. Many wiki’s support Markdown, so it ends up saving me work by just keeping everything in that format.

Even though Markdown’s syntax is very lean and simple, I still end up forgetting some of it from time to time. I find it useful to generate and view the HTML output for the buffer that I’m working on periodically to make sure things look right. This is really easy by setting a custom makeprg for the markdown filetype.

The Hammer Plugin

Robert Gleeson wrote a Vim plugin called Hammer that basically does exactly what I explain here and quite a bit more. It might be perfect for you, but for me it’s much more than I need. I’ve had problems when the version of Ruby on the system is not the same as what Vim was compiled with. Check it out though, you might love it.

A Simpler Approach

All I want is to type :make and have Vim generate an HTML version in /tmp that I can point my browser to. So I put the following in ~/.vim/after/ftplugin/markdown.vim:

set makeprg=redcarpet\ %\ >/tmp/%<.html

Let’s take a quick look at what’s going on here:

The above setting is applied only when editing a markdown buffer. Personally, I use redcarpet to parse markdown, but there are many others that you can substitute here.
Spaces in option strings must be escaped so Vim knows when to stop parsing.
% expands to the name of the file currently being edited.
%< expands to the name of the file without the trailing extension. This allows us to change the name of the file and add the html extension.

So the above command calls redcarpet on the filename and redirects the output to /tmp/<filename>.html. That’s it, super simple. Once this completes, I point my browser to file:/tmp and load the file I’m interested in.

This same approach can be taken with ReStructured Text by putting the following in ~/.vim/after/ftplugin/rst.vim:

set makeprg=rst2html.py\ %\ /tmp/%<.html

Extra Credit

For C, we could set makeprg to call gcc directly instead of make if a Makefile is not found in the current working directory. I find this very helpful when creating a scratch source file to test certain behaviour or a quick theory. Here’s what the contents of ~/.vim/after/ftplugin/c.vim might look like:

if !filereadable(expand(“%:p:h”).“/Makefile”)
    setlocal makeprg=gcc\ –Wall\ –Wextra\ –o\ %<\ %
endif

Now when you load a file of type C and there is no Makefile, typing :make will compile your source file into an executable of the same name (minus the extension). I use this all the time. You could do the same thing for C++ by changing the filename to cpp.vim and changing gcc to g++.

Future Work

It would be cool to copy the target filename to the clipboard for easy pasting into the browser’s URL bar.

New GPG Key

2010-07-20T00:00:00-04:00

I’ve recently set up a new GPG key, and will be transitioning away from my old one. I have done this in order to migrate to a larger RSA key and stronger hash functions, and NOT due to any known key compromise. The old key will continue to be valid for some time, but future correspondence should use the new one wherever possible.

I have created a transition document and signed it with both keys.

Don't Clobber Your Registers

2010-07-02T00:00:00-04:00

I recently needed to call the cpuid instruction from some C++ code. This is well documented on wikipedia and everything went fine until I hit a snag moving the code from x86_64 to i386.

It seems that %ebx is the PIC register for i386, and so you must take care to not clobber it when calling cpuid. This is accompolished by explictly saving and restoring the register before and after the call to cpuid. An additional step is required to tell gcc that %ebx will not be clobbered by the call to cpuid. The last lines of assembly define which registers were potentially clobbered so gcc can generate appropriate code. By manually saving and restoring %ebx, it can be saftely omitted from that list. I did not find any information documenting this specifically, so here it is! The following code returns the result of cpuid and runs on both x86_64 and i386.

void
cpuid(int regs[4], int cpuid_leaf)
{
        int eax, ebx, ecx, edx;
        asm volatile (
#if defined(__i386__)
             “pushl %%ebx;\n\t”
#endif
             “movl %4, %%eax;\n\t”
             “cpuid;\n\t”
             “movl %%eax, %0;\n\t”
             “movl %%ebx, %1;\n\t”
             “movl %%ecx, %2;\n\t”
             “movl %%edx, %3;\n\t”
#if defined(__i386__)
             “popl %%ebx;\n\t”
#endif
             :“=m” (eax), “=m” (ebx), “=m” (ecx), “=m” (edx)
             :“r” (cpuid_leaf)
             :“%eax”,
#if !defined(__i386__)
             “%ebx”,
#endif
             “%ecx”, “%edx”);

        regs[0] = eax;
        regs[1] = ebx;
        regs[2] = ecx;
        regs[3] = edx;
}

For additional information, I found Sam Hocovar’s post to be quite informative.

Find command in $PATH

2010-04-19T00:00:00-04:00

I make calls to external commands from Python quite often. Sometimes it is desirable to know if a command is available on the running system before making a call to subprocess.call(). Here’s the code I came up with for doing that:

import os

def find_in_path(cmd):
    for path in os.environ[“PATH”].split(os.pathsep):
        full_cmd = os.path.join(path, cmd)
        if os.path.exists(full_cmd) and os.access(full_cmd, os.X_OK):
            return full_cmd
    return None

If there’s a better way to do this, or even a builtin python way, don’t hesitate to mention it.

Periodic timers in PyGTK

2010-04-16T00:00:00-04:00

I’ve been writing a ton of Python code lately and I’m absolutely loving it. As a C programmer for the better part of the last 15 years, I find the syntax and ease of expression to be refreshing and fun.

I’ve recently been tasked with writing a GUI interface to an existing product we have at MiserWare called Granola — a free (as in beer) version of our enterprise power management solution.

I found myself needing a periodic timer to update the window with new statistics coming in from the daemon. You can do this in regular python, but PyGTK, specifically gobject, makes it very easy. Here’s an example that draws a simple window with a label displaying the current counter.

#!/usr/bin/env python

import gtk, gobject

class PerodicTimer:
    def __init__(self, timeout):

        # create a simple window with a label
        self.window = gtk.Window()
        self.window.connect('destroy', lambda wid: gtk.main_quit())
        self.window.connect('delete_event', lambda a1,a2:gtk.main_quit())
        vbox = gtk.VBox()
        self.window.add(vbox)
        self.label = gtk.Label('Periodic Timer')
        vbox.pack_start(self.label)
        self.window.show_all()

        # register a periodic timer
        self.counter = 0
        gobject.timeout_add_seconds(timeout, self.callback)

    def callback(self):
        self.label.set_text('Counter: ' + str(self.counter))
        self.counter += 1
        return True

if __name__ == '__main__':
    periodic_timer = PerodicTimer(1)
    gtk.main()

The bulk of the code is just setting up a gtk window, the timer code is only 5 lines or so. As long as callback() returns True, the timer gets re-registered for the original timeout value (1 second in this example). One caveat I found, gobject.timeout_add_seconds() seems to depend on the GTK main loop, so you cannot use it from a regular non-GTK python application.

Byobu Rackspace Cost Plugin

2010-01-23T00:00:00-05:00

If you haven’t heard of Byobu you’re missing out. It’s an enhancement to GNU screen that, among many cool features, allows users to define their own plugins and have them displayed in the statusbar along the bottom of the terminal.

The default installation comes with a plugin that displays the approximate Amazon EC2 cost of the running instance. I wanted a plugin that worked for Rackspace servers, so I modified it and implemented the Rackspace Cloudserver pricing model to create byobu-rcs-cost. Documentation is in the README, it’s pretty straightforward to install and use.

Now I can quickly see the estimated cost of each server I’m logged into, pretty cool.

Update: This plugin was merged into the official byobu release as of version 2.73. See the byobu project page for more details.

Ubuntu Resource Management

2009-10-13T00:00:00-04:00

I recently wanted to limit CPU usage on my Ubuntu Karmic workstation. Since libcgroup is included in the upcoming Karmic release, setting up cgroups on an Ubuntu server has never been easier.

The Goal

My needs were as follows:

My machine is dedicated to running an Apache Web Server and I would like for it to have priority on the CPU whenever it’s needed.
I have an occasional user on my system that chews up CPU like it’s going out of style and slows down my web server. In this example, we’ll call this user kirkland.

The goal is to only allow kirkland CPU cycles when no other process is requesting them. Similar to a sponge, kirkland will be throttled to 0 if my apache daemon is really busy.

Getting There

Install libcgroup:

$ sudo aptitude install libcgroup cgroup-bin

Edit /etc/cgconfig.conf, define a sponge group:

group sponge {
    perm {
        task {
            uid = kirkland;
            gid = kirkland;
        }
        admin {
            uid = root;
            gid = root;
        }
    }
    cpu {
        cpu.shares = 1;
    }
}
mount {
    cpu = /mnt/cgroups/cpu;
    cpuacct = /mnt/cgroups/cpuacct;
}

Edit /etc/cgrules.conf, assign kirkland to the sponge group:

kirkland         cpu             sponge/
*                *               sysdefault/

Restart cgconfig and cgred services:
```
$ sudo service cgconfig restart
$ sudo service cgred restart
```
Processes created by kirkland should now automatically get moved into the sponge cgroup and will only recieve CPU cycles when no other processes are in need.

For more information about libgroup, you can visit the libcgroup project page. And for cgroups in general see the current kernel documentation.