I’ve grown increasingly unhappy with WordPress, despite the fact that it’s served me fairly faithfully for over seven years. The main reason is performance—this blog is now just too slow to load. There are definitely things I could do to tackle that, but having to do so is a sign that it’s not the right platform. The other reason is philosophical—I no longer think that a web application backed by a database is the best approach for a blog.
I’ve been thinking about writing my own—of course. So first I should establish the requirements.
I switched to writing in reStructuredText in mid-2009, and to writing in Vim in early 2010. Since then I’ve made a lot of tweaks to improve editing efficiency, and eventually collected these in a Vim plugin (and a Python script). The following discussion of that plugin might be of interest to anyone concerned with writing efficiency and/or editor customization.
I use plain text formats for all of my writing, and you should at least consider doing the same.
By “plain text” I mean not only a text (as opposed to binary) file format, but also something that is plainly readable when simply listing the contents of the file—that is, a format you don’t necessarily need a specific tool to read. Such formats are more flexible, more robust, more malleable, and more future-proof than more complicated alternatives.
I’ve been experimenting with using terminal Vim in a tmux environment recently. I like it as a programming setup, primarily because of the ease with which I can set up new workspaces and switch between them—without, of course, having to move my hands off the keyboard. I did encounter some annoyances along the way, and my solutions for them are included below.
I’ve cared about typographically correct punctuation (as well and as distinct from grammatically correct punctuation) for as longer than I’ve had a computer. The difference between typical home computer output (and display) and typography as seen in books was always glaringly evident, and I wanted to narrow that gap as much as possible. This post is a discussion of some of the issues, how I’ve handled them in the past, and my current approaches.
I’ve mentioned pandoc once before, and it’s again proved rather useful. I’ve been looking for more ways to use it, as I love its core principle (although I naturally wish that it focused on reStructuredText rather than Markdown) of being a comprehensive text format converter. It might at one point be the answer for getting from reST to PDF—something that the current reST tools don’t help me with because I insist on using Unicode, and XeTeX isn’t yet supported. But today pandoc helped with a different task: going from reST to plain text.
These aren’t anything particularly major, just some things I’ve found to improve my editing experience.
This post is about keyboard shortcuts, remappings, application switching, and a little bit of workflow, primarily in the context of OS X and Vim, so it might not be of interest to all readers.
I’ve been slow in upgrading to MacVim 7.3, which came out about a month ago. I’m happy with it, but there are only a couple of features that really matter to me so far:
- Python 2.6 support.
colorcolumn lets you specify columns that will have a different background color—this is primarily useful for source code where you want to stick to line length limits. This is one of the few features I was still missing from jEdit, although I think jEdit’s solution was nicer: in jEdit the visual line was thin and went between the columns, so between columns e.g. 79 and 80 you could have a line; in Vim 7.3 either column 79 or 80 would have a “line”, i.e. a different background color. Still better than the kludge I use now, though.
Python 2.6 support is nice due to the number of Python scripts I’ve written for Vim, which used to have to be compatible with Python 2.3. The main things I really like here are the ability to use .format on strings, conditional expressions, built-in set support, and generator expressions. That list is inspiring me to edit some of my old scripts right now.
The current interface upheaval is centered on touchscreens. I think this is an important step, and one which may allow for some significantly different interaction paradigms to emerge. I wonder how long touchscreens will remain dominant, however, even though the interfaces they help spawn may stick around for a long time.
After a highly enjoyable, productive, and extended period, it’s time for me to return to the world of paid work.
I’m quite happy with the things I’ve done during my time off. Many of them are important only to me, but then, it’s been my time off.
Permalink 3 Comments
, document formats
, text editing
This post could be summarized as “regular expressions are a lot faster than naive for loops”.
I’ve been working on improving the script I use for live wordcount in Vim, partly for performance and partly so that I can package it up as a plugin and share it with other people. Along the way I’ve improved the speed of the script rather significantly, and will go through the key part of that change here.
It’s possible to get Thunderbird to use Vim as an external editor for email, and while it’s a little clunky, it works.
I played Killer Instinct a lot in the mid-90s. It didn’t have the multiplayer depth of Super Street Fighter II Turbo, but I wasn’t playing it multiplayer much—rather, I was trying to get the longest combination move I could.
But what does this have to do with text editing?
I remain rather happy with Vim, and it’s already been worth the effort of switching over to it. I’ve encountered some annoyances along the way; here are a couple of them and some solutions.
The first is that I quickly found myself wanting to exit Insert mode very frequently and not liking the stretch from my typical hand position to the Esc key. I know that some people insist that the only way to deal with this is to remap CapsLock to Esc, while others remap CapsLock to Ctrl and use Ctrl-C instead of Esc to get to Normal mode. Neither of these approaches appealed to me. Seth reminded me about another approach, one I thought would be too awkward: mapping jj to Esc within Vim.
As a result of my porting over jEdit (Jython) macros to Vim, I now have a fair amount of (Python) Vim scripts, and have learned some things about how to set up those scripts. I’ll go through some of that below, and hopefully other people writing Python scripts for Vim will find it useful.
Over the last couple of weeks I’ve been hacking away on scripts to customize Vim, replicating the scripts I made for jEdit. I’m more or less done, and this blog post is being written in MacVim. This hopefully means that when I’m done with it I’ll be able to publish it from within Vim, the same as with jEdit.
I’m currently trying out Vim (again), and have made more progress this time, mainly due to Seth’s help. The key things that have made it better:
- :set hidden. Absolutely critical, this. Stops Vim from complaining when you try to switch buffers and your current buffer has unsaved changes.
- bufexplorer. Makes switching buffers a lot easier.
- A better Python syntax file. I didn’t like the defaults.
- My own indentation and syntax files for reStructuredText.
Really, though, the key first one was :set hidden. Before that I felt that I had completely misunderstood Vim’s file management model.
There are three kinds of major text editors: Emacs, vi (now really Vim), and “other”. I’m sure there are some other quirky small ones out there, but those are basically the major categories. “Other” encompasses what I think most people would expect from a text editor: a window in which you can type freely and see your text appear, and which behaves somewhat like other applications, including word processors, in its basic functionality.
I’ve used the “other” category for years. I think that the first one I used heavily (I’m not counting MS-DOS Editor) was TextPad. I stuck with that for quite some time, and then started using HomeSite. I think I played with UltraEdit for a while too. Eventually, however, I wanted a cross-platform and free software editor, and shifted over to jEdit. I’ve used it heavily for several years, and consider it the best of the “other” class.
I have, however, always thought about making the effort to learn vi, because I’ve always loved the keyboard-only approach and like to save time by making my text editor use more efficient.