Chad Perrin: SOB

26 February 2009

Vim for New Users

Filed under: Geek — apotheon @ 12:36

Vim is an editor that requires a significant early investment to learn how to use with any effectiveness. It then takes a significant early investment to get comfortable using it. After that, you could spend the rest of your life learning to use it, learning something new about it every single day, and still have more to learn after forty years. The investment in the learning curve is definitely worth it in my opinion, however, as the productivity gains I have achieved using Vim, and the comfortable intuitiveness of it, by far eclipse any initial investment in learning it.

Note that this is all predicated upon the assumption that you touch-type using a QWERTY keyboard layout. If you don’t, you’re better off using something like SciTE instead. An editor doesn’t get as intuitive and productivity-enhancing as Vim is without doing so for a strict subset of typists, and the primary assumption on which Vim relies is that you’re a QWERTY keyboard touch-typist. I hear it works reasonably well for Dvorak keyboards, too, but there are one or two things that end up slightly “off” unless you change some of the defaults for Vim commands.

Getting Vim

Vim is open source (but, alas, not copyfree) software that is in the software management archives of every major open source Unix-like OS in existence, including BSD Unix systems and Linux distributions. As such, installing is trivial on such systems. Check the software installation process particular to your open source Unix-like OS of choice for details.

I recommend getting the console-based Vim and using that at first, if that is reasonably possible. If you are using MS Windows and aren’t the type to use Cygwin or some other Unix emulation environment, though, you should probably use gVim instead. GVim is a version of Vim that comes with a GUI interface, complete with clicky buttons, and is pretty much a necessity if you want to use Vim in a standard MS Windows environment because of the severely crippled support for console-based applications on that OS. Other than under such circumstances, the only time I’d recommend gVim is when you try out the console-based interface first and discover that you just can’t handle a more keyboard-driven text editor at first and need a more gentle introduction to modal, keyboard driven editors.

Before giving up on the console-based interface, though, try it out for a few days (or, if you don’t do much text editing in an average day, maybe longer).

Anyway . . . if you’re on an OS that, like MS Windows, doesn’t have a modern software management system, or you want to install Vim outside of your software management system for some reason, you can download Vim from the Web. Many open source Unix-like OSes come with Vim already installed, though, so you may not even have to install it. Be aware that some of them (such as Ubuntu) have a “slim” version of Vim installed by default instead of the standard Vim editor, however. This lighter weight version lacks some functionality, and if you don’t have a compelling reason to use the smaller version, you should probably just install the full-size version. Even the standard, full-size version is smaller than two megabytes, last I checked, so you aren’t likely to consume an undesirable quantity of storage space on your hard drive.

Starting Vim

With less productive, more GUI-oriented text editors (how do you like the way I slipped that bias in there?), you’re probably used to opening a text editor, getting a blank, untitled file, and filling it with text before deciding on a name and saving it. You can do that with Vim, too, but I recommend you adopt a different approach when using it. Instead, specify the name of the file when you first open it.

The console-based Vim is started with a command entered at the shell prompt. You’ll probably do this within a terminal emulator such as KTerm, GNOME Terminal, ETerm, XTerm, the MacOS X Terminal, or rxvt. Entering the command vim is enough to open the editor, but to open it by specifying a file name (such as an existing file you want to edit or a new file you create at that moment), you would enter something like:

vim filename.txt

Part of the reason I recommend specifying the name in advance is that Vim caches your file to the hard drive every now and then by default in case of a crash (as in the case of someone tripping over the power cord of your computer and causing it to be unplugged while you’re in the middle of typing). The next time you open the file, if you specify the same file name, it will offer options for recovering the file from that cached version of the file. Otherwise — well, I’m not really sure what it does, otherwise, because I’ve never had to find out. Maybe it doesn’t create a cached version until after the first time you save it. Maybe it uses some cryptic name based on the time and date, or a default name. I just think it’s a good idea to name your file when you open it. If you disagree, do things differently.

Using Modal Editing

When learning Vim, the first thing you need to know is that it uses modes for different parts of its operation, and if you start trying to enter text while you’re in the Command mode you can do all kinds of weird damage to a text document. Luckily, you can probably undo the damage very easily, as long as you don’t accidentally save and exit the program while you’re busily doing damage.

The program starts up in Command mode. In Command mode, you can use single-character keyboard shortcuts and typed commands that start with a colon to achieve quite a lot of very efficient editing very quickly with very few keystrokes (once you learn how, and get familiar with it). Actually, Command mode is what it’s called in old-school vi; Vim is an extended, “improved” version of vi. Vim calls it “Normal” mode, which I find silly, so I keep calling it Command mode.

To start actually entering text normally, you need to enter Insert mode. Do that from Command mode just by pressing the <I> key. To exit Insert mode, going back to Command mode, press the <Esc> key.

To undo changes, pres the <U> key while in Command mode. The entire last time you were in Insert mode, complete with any changes that were made in Insert mode, is considered a single change for purposes of undo/redo. To redo something you just undid, type :redo and hit enter — the : tells Vim you’re going to type a command.

Saving and exiting must be done in Command mode. To exit without saving, use the q! command (i.e., type :q!). To save without exiting, use the w command. To save and exit all at once, you can use the x command. To specify a filename when saving it, in a sort of “Save As” situation, you can do so with a command like:

:w filename.txt

Finally, it might help to understand the philosophy of modal editing. For that, Why, oh WHY, do those #?@! nutheads use vi? is what I recommend reading.

Learning Vim

You really just have to use the hell out of it to get comfortable. It will probably prove somewhat difficult at first, but as I already said, I think the initial learning curve is well worth it for the long-term productivity gains. If that’s not true for you, c’est la vie.

A few resources for learning more:

  • If you have Vim installed on your computer, you should be able to start a tutorial for it by entering vimtutor in a terminal emulator window.

  • There’s a built-in help system in Vim that you can use to search Vim documentation for how to perform specific tasks. It doesn’t always provide the most intuitive approach to finding what you need, but you get to it by typing something like :h search in Command mode, where “search” is a search term. In fact, if you literally enter :h search in Command mode, you’ll get help information on how to search a document for text that matches a particular regular expression.

  • The same site that offers the explanation of the philosophy and benefits of modal editing, linked above, also offers some vi/Vim tips.

  • The Vim Tips Wiki might be of some use to you.

  • So might Mastering the VI editor.

  • Be sure to check out the Vi Lovers Home Page.

  • You might want to bookmark a Vi Cheat Sheet. This is just one of many on the Web.

  • An excellent book for learning about how to make your way around in a Unix-like environment without the GUI — good for both experts and novices — is A Practical Guide to Linux Commands, Editors, and Shell Programming. It has a decent section on vi/Vim in it, too.

  • More resources can be found on the Vim subreddit.

. . . and Beyond

Hopefully, you find that helpful. I’ll probably provide some Vim usage tips that I’ve found particularly helpful and somewhat unobvious in the near future.

Once you really learn how to use vi/Vim, you can learn to throw the vi gang sign, and be a vi gangsta.

23 February 2009

Advocacy’s Fifth Column

Filed under: Cognition,Geek,Liberty — apotheon @ 04:14

During the Spanish civil war in the 1930s, insurgent general Emilio Mola announced in a radio address that the four columns of his forces attacking the city of Madrid would be aided by a “fifth column” inside the city. What he referred to was not so much a literal military column, but supporters inside the city who would sabotage the efforts of the defenders. While they were not terribly effective — the city held against the siege for a few years — that doesn’t mean the idea itself is bad. In fact, in some cases, it can make a critical difference.

The concept of a fifth column, taken to a metaphorical extreme, is an often overlooked approach to increasing the effectiveness of an advocacy movement. Sometimes, the best way to convert someone to your way of doing things is to trick him into doing it on his own without even realizing it. An example that comes to mind is something a friend encountered in an economics class in college.

On the first day of class, the instructor described a hypothetical situation: you run a small business, and you have a competitor across the street. You both sell the same thing. You sell a good product; you charge reasonable prices; you treat your staff well and inspire them to give good customer service. Your competitor sells a shoddy knock-off product; he charges unreasonable prices; he treats his staff and customers alike with contempt. His business founders, and eventually goes bankrupt.

The instructor then asked each and every student in the class “Do you think you owe him a living? Should you have to pay him to start his business again?” Actually, he probably asked the question better than that. Each and every student in the class said no — of course I don’t owe him a living. That’s ridiculous. It’s his own fault he screwed up his business, and his former customers are probably better off without him anyway. When each person had answered, the instructor stood at the front of the room and proclaimed them all Objectivists.

I’m sure he didn’t actually convince them all they should be Objectivists that day, but he made a good point — and a number of his students probably really woke up to some realities of economics in that class because of the first day’s demonstration. Some of them may even have become Objectivists (though I’d hope they just became Austrian economists, or something like that). Any such successes would, of course, be at least in part attributable to a metaphorical fifth column tactic: get someone to adopt something in practice first, then get that person to recognize the principle behind the practice. At that point, it’s more a matter of getting someone to recognize he already is what you want him to be than to actually convert him directly.

This is just one example (among many) of where the Free Software Foundation is dropping the (four thousand pound lead) ball (on its own foot). The FSF faithful, with its collective focus on pure adherence to the “Free Software” philosophy, is actually turning people off about as much as it’s attracting them. I believe that at least 98% of that philosophy’s converts got there despite the best efforts of its strongest advocates. These are people who threaten legal action against open source projects who aren’t sufficiently pure, insult people who use the term “open source” instead of “Free Software”, and use a nine hundred pound pile of paperwork that favors the code’s “freedom” over the freedom of its users and developers as a license — a contagious license that many businesses are afraid to touch.

Gateway Drug

That license, and the entire copyleft licensing philosophy, actually serves to cut off the potential use of a fifth column tactic entirely in many cases. When I say successful conversions happen despite the best efforts of the most prominent advocates, I mean it. Many of them come by way of fifth column tactics that occurred essentially by accident. People start out using something like Firefox (the gateway drug of open source software), then once they’re comfortable with that they use other open source software like Thunderbird and Pidgin, and eventually they end up giving something like Ubuntu a try. Gradually, they find themselves using more and more open source software, until they find themselves actually advocating open source software for the openness of it to others. Some of them end up on the Free Software side of the Free vs. Open Source divide.

When Google finally moves things forward, we’ll get something like the Firefox fifth column attack for copyfree licensing as well, in the form of the Chromium open source browser project. The Google branded release of the Chromium browser is, of course, Google Chrome, and Google is currently working on a Linux port of the thing. While Google may not do so itself, I’m believe others will make the effort to port it to FreeBSD, thus providing — mostly by accident, I’m sure — a migration path from MS Windows and/or MacOS X (another target for a Google Chrome port), through Linux-based OSes, to FreeBSD. That, I’m pretty sure, is where FreeBSD gets most of its “converts”, in fact: people who previously moved from MS Windows to some Linux distribution. That’s how I ended up using FreeBSD. In a way, FreeBSD is to the Linux world what Linux-based OSes are to MS Windows.

The same kind of fifth column approach has been known to work for the Libertarian Party, too. The local chapter’s board chairman has taken that approach to getting converts, and has done a pretty good job of it; he maneuvers people into expressing opinions that are aligned with libertarian principles, then gets them to recognize those principles and apply them to convert themselves. This is a far more direct and intentional approach than what I’ve seen in the software world, where everybody seems to think that the best way to convert someone is to tell that person his or her opinions are all wrong. They may very well be wrong, but that’s not really guaranteed to be effective.

In Why functional programming doesn’t catch on, the point is made that a lot of functional programming advocacy fails because it is too abstruse. The author contends that what is needed is more earthy, practical examples of the benefits of functional programming. Well, sure — that’s important, especially for convincing hobbyists with nothing better to do than learn a new programming language that don’t usually get used for professional purposes. Even that isn’t going to make inroads to professional use very quickly, though. Get enough hobbyists on your side, and eventually it’ll start seeping into professional circles, but that’s a very slow, and very weak, motivational plan.

Try the fifth column approach instead. I kind of brushed up against that approach when I wrote Functional programming techniques can improve software security about six months ago. Even in that, though, I wasn’t really doing as good a job of it as I could have (if advocating for functional languages was my goal — which it wasn’t, exactly). I did all the right stuff, talking about how one can employ functional techniques within more traditionally imperative languages to good effect rather than just suggesting that people quit using Java right now and use Lisp instead. I put the emphasis in all the wrong places for effective fifth column advocacy, though. If I wanted to maximize the fifth column approach’s effectiveness, I wouldn’t have put “functional programming” in the title, and would have made the article about technique, without making a big deal about functional programming.

I would have gone more gently, in other words. I would have set out to teach something without putting the fact that what I was talking about was functional programming techniques in the center ring with all the spotlights on it. I would have mentioned these were techniques borrowed from the functional programming paradigm, of course, but only in passing. I would have also probably mentioned that, while these techniques are best suited to use with certain functional programming languages (with examples), they can also be used (though not quite as easily) to some good effect in traditional Algol-descended imperative languages (including many nominally object oriented languages) too, but only in passing.

I haven’t really thought much about the value of fifth column tactics in advocacy efforts in the past, but the more I think about the differences between copyleft and copyfree licensing policies, the more obvious and evident it becomes. Now that I’ve put more thought into it, I’ll keep my eyes open for more opportunities to make use of such tactics in the future.

22 February 2009

By the way — I hope RPG Bloggers comes back.

Filed under: Metalog,RPG — Tags: — apotheon @ 07:02

I visited RPG Bloggers today, only to find a blank white screen with the following text on it:

Error establishing a database connection

. . . in big, bold, <h1></h1> black text. Ah hope it ain’t broke fer ever.

Older Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License