subscribe via RSS
I recently participated in RogueConf, a small Bulgarian conference. I talked about documentation, how and when to write it, how to write tools to help you out. The video is on youtube, and the slides are on speakerdeck, though it’s all in Bulgarian. This post is the TL;DR of the talk. I’m going to run through my main points, skipping over the demos and most of the examples. Eventually, I’ll extract some simple documentation tools from work in the dawanda/doctools repository, but there is still some effort needed to make them generally usable, I’m afraid.
An interesting tool I discovered recently is git-all. It shows you the status of all git repositories in the current directory that have changes or require pushing. This is pretty useful with my “projects” directory – I could have forgotten to push some recent commits, or I might have started working on something and need a reminder to finish it.
The program is written in haskell and I decided that it’s small enough to use for haskell practice. My original intention was to add support for colors, but I found an odd bug that I ended up fixing instead. In the process, I learned one or two interesting things, so I’d like to explain them for someone else’s benefit. If you have some haskell knowledge, but you’re still in the “beginner” category, you might find the small nuggets of information useful.
I’ll start by covering several things about haskell I learned during the process. After that, I’ll describe the actual problem and how I managed to solve it. Note that I’m very inexperienced in this area, so take my thoughts with a grain of salt.
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.
I finally bought an Arduino to play around with. Considering I’m studying robotics, it’s a good first step. If the word doesn’t ring a bell, an “Arduino” is a simple programmable chip. You can write code (a “sketch”) in a subset of C++ and then upload it to the board. You can wire all kinds of sensors and motors to the Arduino and build some pretty cool stuff (a sliding door, a portal turret plush toy).
Naturally, starting something new, I ran into a few bumps. While there’s a ton of information on the Arduino forums, and even in the Arch Linux wiki, it was still a bit of an adventure to get the ball rolling on my machine.
In this post, I’ll describe the solutions to a few of my issues. I’ll also explain how the compile and upload process works, at least to the extent of my understanding, and how to get started with building through the command-line. So, if you’re not interested in my headaches, feel free to jump down to “Step 1: Preprocessing”.
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.