I spend most of my development time in the shell - be it editing text with Vim or executing various console commands. I have quite a number of tricks in my daily repertoire, and I would like to share three tips today.

Edit current command with a text editor

I often end up having to change a long command I just typed, and using arrow keys to get to the correct spot is not favorable. Bash has the feature which lets you edit current command in a text editor of your choice. Hit Ctrl + x, Ctrl + e (or Ctrl + x + e), and you will be dropped into your text editor. Now you are able to edit the command, and it will be executed as soon as your write the file and exit the editor.

You can use an editor of your choice by adding following line to your .bashrc file:

export EDITOR=vim

Replace vim with the name of your favorite editor.

Update: It looks like for some machines setting EDITOR variable is not enough. In this case, you also need to set VISUAL environment variable.

Edit recent command

You can edit your recent commands in a text editor of your choice by executing fc beginning_of_the_command. For instance, if you run fc l, you will open most recent command starting with the letter “l”.

You can execute fc without any arguments to edit last executed command.

Bash history autocomplete

Another great feature - “reverse intelligent search”. If you hit Ctrl + r in your shell, you’ll be greeted by the following prompt:


Start typing a part of the command from your history, and you’ll see suggestions popping up. Hit Enter to pick the command (you’ll be able to edit it before executing), or push Ctrl + g to return back.

Like any of these tips? Have some of your own? Don’t hesitate to share those in the comments section down below.

Recently I’ve been writing much more than I used to: long emails, software documentation, personal Wiki, keeping work journal, blogging, writing challenges… Luckily enough, I do all of this writing in Vim. But sometimes writing prose in Vim might feel a bit unnatural, especially if you have a wide screen: text will be on the very left side of the screen, or (if textwrap is not enabled) you’ll end up with lines hundreds of characters long. And overall, editing text in Vim sometimes might feel a bit clunky - with all the extra information and high-tech (or low-tech, depending on your perspective) look.

I found a simple, yet sufficient solution for this issue: VimRoom. It’s a Vim plugin which enters distraction-free writing mode, by centering the 80-character block of text on your screen. It’s highly configurable, and I found it to look especially pleasing on vertical monitors (which I prefer to use for writing). It looks presentable even on smaller screens though, here’s a screenshot:

Install the plugin (use a package manager like Vundle or Pathogen to simplify the task) and add a following line to your .vimrc:

nnoremap <Leader>vr :VimroomToggle<CR>

Now, hit <Leader>vr to drop in/out of the VimRoom mode (<Leader is a backslash \ character by default).

GitHub link: https://github.com/mikewest/vimroom.

I finally did it! I’ve left the dark corners of WordPress in favor of Octopress, which seem to be the best system for my blogging needs.

Why the migration?

WordPress was a great host for me at one point - the community is fun and no work is required for setup (I would rather not waste time fiddling with my blog too much). But a number of things are off-putting:

  • I don’t like WYSIWYG editors and I don’t like web editors. I try to use my favorite editor for everything, including mail, documentation, note taking. Even though WordPress allowed me to write my posts using Markdown, I still didn’t like not being able to use my favorite editor or environment.
  • Storing all the entries in a MySQL database is not favorable. I am writing text, why would I pick any other format to store what I wrote?
  • Over the years my blog became increasingly slow, and in order to have a reasonably fast site I needed to pay quite a sum of money. I am not ready for such a commitment, since I only occasionally update this blog.

On the other hand, Octopress (which is based on Jekyll, a static site generator) has all of these concerns covered:

  • I can write by creating simple Markdown documents. It doesn’t matter where I write, or how I write. This enables me to use an editor of my choice.
  • Plain text is universal. It can be viewed by a human, edited in any piece of software, printed out, emailed, piped to a Linux program - just about anything really.
  • Static sites are ridiculously fast. There’s no preprocessing and no rendering. The only real speed limit is network latency. In addition, GitHub lets you host static sites for free. What else could you ask for?

The process is painless

Switching from WordPress to Octopress was very easy, and it took me only a few hours (spread out throughout one weekend). Some highlights:

  1. Comments in Octopress are handled by Disqus, and I had to set that up on my WordPress blog before transitioning in order to transfer all the comments.
  2. I used the WordPress to Jekyll Exporter tool to export all my posts from WordPress to Markdown (with meta-data which Octopress understands). I only had a bit over 50 posts to worry about, so the process was complete in an instant.
  3. I ran some custom Vim macros to remove and change some excess meta data, as well as clean up Markdown formatting. I am a perfectionist, and the exporter tool left me with a poorly formatted document. I couldn’t let that happen.

Results are breathtaking

After only a few hours of work, I had a lightning fast, simple, and pragmatic blog. There is no excess configuration, comments are handled externally, and the source code for the site and articles is available on GitHub. I am able to write my posts using Markdown, in my favorite editor, and use git to publish the resulting articles.

I just finished reading “The Pragmatic Programmer” by Andrew Hunt and David Thomas - two consultants behind Pragmatic Programmers, LLC. This book might as well be a fantastic marketing trick for their consulting agency, but the value it brings to the reader is hard to underestimate.

Hunt and Thomas cover a wide variety of topics, briefly glancing over every major aspect of developing software: be it the choice of a text editor, calculating time complexity, or working effectively on a team.

If you read thematic books and actively follow programming blogs and podcasts - you may find yourself cheerfully nodding while reading sections of this book. You may have read about some of the tips online, heard from colleagues, or simply discovered them yourself. You will finish this book with a wide smile of approval, and a sense of validation in regards to your daily work flow or actions.

If you are less lucky (say, you don’t read as much), you will find 70 tips you can utilize right away, right now, at your workplace. This is what “The Pragmatic Programmer” essentially is: a collection of practical things regarding getting things done.

It’s an essential read, and I’ve seen this book in every single recommended reading list out there. And for a solid reason. This is the kind of book you want to re-read every couple of years to absorb every piece of knowledge presented within it. The latest edition of the book even contains a printout with all the tips listed in the book.

You should read it after being in the field for a few years. After making mistakes, and figuring some things out on your own. Beginners might not understand some pieces, but will still be able to comprehend a major portion of knowledge contained within this book.

I enthusiastically recommend this book to every software engineer I get to work with. It’s easy to read (as opposed to monstrosities like “Code Complete” or “Art of Computer Programming”) and it teaches you how to get things done, the pragmatic way.

I recently found an interesting way to organize random bits of information: a personal Wiki. It’s a great idea to have data repository shared between your machines: important notes about people, conversations, events, tasks you’ve accomplished, thoughts, and a hundred of little pieces of knowledge which don’t belong anywhere else. There is plenty of software out there which lets you set up a personal Wiki, and some of it is very lightweight and well polished. However, I prefer to do most of my editing and writing in Vim. As tip #22 from “The Pragmatic Programmer” states:

Use a single editor well

We think it is better to know one editor very well, and use it for all editing tasks: code, documentation, memos, system administration, and so on. Without a single editor, you face a potential modern day Babel of confusion.

I fully agree with the above statement and I try to use one editor for the majority of tasks which require typing, without having to remember which editor contains certain features, and which doesn’t. That’s one of the main reasons I went with vimwiki - a lightweight and clean personal Wiki with it’s own Wiki-style markdown. Oh, vimwiki also subscribes to another tip from “The Pragmatic Programmer”:

Keep knowledge in plain text

The vimwiki plugin has a number of interesting and useful features:

  • Memorable mappings for moving in and out of Wikis. Hit <leader>ww and you are on the home page of your Wiki. The <leader>wt will open the Wiki in a new tab: the rest of the mappings are as intuitive.
  • Multiple Wikis support: really handy if you have a number of separate projects for which you want to keep separate entries.
  • Diary-like quick notes. You can create an instant page for today by hitting <leader>w<leader>w. Combination <leader>wi brings you to a diary home page, and <leader>w<leader>i re-indexes the diary entries.
  • Easy link creation: hit enter on a word and it will turn into a link to another page. Hitting enter on a link will transport you to the destination page. Simply surrounding text with double square brackets ([[]]) works as well.
  • Navigation: enter to follow a link, backspace to go back.
  • You can convert all your records into html by executing :VimwikiAll2HTML.
  • Extensive and well written help file. Just run :help vimwiki and start reading.

The list can go on forever, but these are the features I found to be the most useful.

In order to enjoy synchronization between all my machines, I hosted my Wiki in a Dropbox folder - vimwiki lets you specify locations from each one of your Wikis.

let g:vimwiki_list = [{'path': '$HOME/Dropbox/wiki'}]

Download it from the GitHub: https://github.com/vimwiki/vimwiki.