Category Archives: HowTo

Nano as a Focus Oriented Editor

One of my previous blog posts dealt with using Markdown for writing. Once its clear what markup to write in, another question pops up: which of the humongous number of text editors to choose? I’ve been sniffing around for an editor that fits me for quite some time now and I feel like I’ve tried them all: Gedit, Geany, Notepad++, Moe, Vi, Vim, Emacs, Sublime, Brackets, Atom, Light Table… and Nano.


Obviously not all, but still. I find it somehow paradoxical that after all the spoiling from editors that are feature packed to the roof, I ended up with Nano. And with ended up I mean: I haven’t changed my editor for a while, I’m quite happy about the setup, I’m able to work efficiently and when I try a different editor, I’m naturally drawn back.

With all those shiny next generation editors around, why choose an editor whose history reaches to 1990s and which can be operated only from the command line? Well, because Nano helps me to solve these problems quickly and easily:



  1. Focus. This has been a major problem for me. No matter how good your editor is, if you get distracted by the web browser lurking in the background, you still don’t get much done. This is why I turned to command-line editors in the first place. Having a full screen terminal, or being on a separate tty really helps to channel the attention. And if some distractions still remain, you can go as far as slapping your old useless PC with a headless system and unplugging it from the network. Still feel like in the need of a new simplistic focus oriented editor?

  2. Keyboard utilization. Being a command line editor, you can rest assured that Nano won’t force you to constantly oscillate between keyboard and mouse. And it gets even better, there are keyboard shortcuts for all actions using the alphanumeric keys. This will surely please all the touch typing keyboard ninjas out there. I know it makes me happy.

  3. Custom syntax highlighting. Need one? Know regular expressions? No problem then. Just write the rules into the .nanorc file and you’re done. This comes really handy for me as I use the Pandoc’s version of Markdown, which is usually not well supported by the out-of-the-box syntax highlighting in other editors. Here’s the custom syntax highlighting I use:

syntax "markdown" ".txt$" ".md$" ".markdown$"
# Emphasis
color magenta "[^]_"
color magenta "*[^*]
# Strong emphasis
color brightmagenta "**[^*]**"
color brightmagenta "[_]*"
# Underline headers
color yellow "^====(=
color yellow "^----(-)"
# Hash headers
color yellow "^#.
# Inline HTML tags
color brightblue start=""
# Inline footnotes
color green start="\^[" end="]"
# References
color brightgreen "@([a-z]|[0-9])+"
# Links
color blue "[.](.)"
# Code spans
color cyan "[^]*`"
# Quotations, lists, horizontal lines, newlines and footnote marks
color brightblue "^> "
color brightblue "^- "
color brightblue "^* "
color brightblue "^[1-9][0-9]?[0-9]?. "
color brightblue "^---"
color brightblue "\$"
color brightblue "[\^[1-9][0-9]?[0-9]?]"
color brightblue "[\^]"
# Todo
color ,red "TODO"
# Trailing whitespace
color ,red " +$"

For more information on how to set up the nanorc config file, see this page.

Okay, maybe I turned this post into an advertisement for Nano. Luckily, it’s free and that should drive the accusations away :) To balance this, I will add one thing that I miss in Nano and that is snippet support. But, there is a workaround for this, just follow these steps:

  1. For each snippet you want to have, create a text file that contains only it.

  2. Put them in a folder, and open your other files from within that folder (it will make this folder the default one Nano looks into when opening new files).

  3. This step applies only if you have enabled the support for multiple buffers: Once you have opened a file you want to edit, hit alt-F to tell Nano that the contents of files you choose to open should be inserted into the current buffer (this setting lasts until you quit Nano or until you hit alt-F again).

  4. Now if you need one of the snippets, hit ctrl-R to open a file, type the first few letters of the file which contains the desired snippet, complete it with Tab and hit Enter.

And that’s it, now you have the snippet at cursor position. It’s not perfect, there are no placeholders for cursor positions, but well… for Markdown with occasional HTML comments? Good enough.

Okay, enough rambling from me. To the machines!

An efficient way to convert Markdown to a Word readable format

In my previous post I pointed to some of the advantages Markdown has for writing. However, sooner or later you arrive in a situation where you need your text in the .doc / .docx / .odt format. Obviously, you google how to convert it and you end up with the good old Pandoc. This program works great for converting almost any type of documents. But recently I discovered that there is more to it than just:

pandoc -o output_file.odt

Here are two ways to spice it up. First, use the --smart argument which ensures that straight quotes are converted to curly quotes, two dashes to an en-dash etc. In other words, Pandoc will attempt to produce a typographically correct output. Similarly, the --normalize argument removes repeated spaces and makes other corrections.

Second, you can use the --reference-odt or --reference-docx arguments, depending on which format you want do convert into. This points Pandoc to a reference file whose styles should be applied to the converted text. It allows you to pre-define the formatting of headings, paragraphs and other parts of text so that you don’t have to do this manually after every conversion. All in all you would use:

pandoc --smart --normalize --reference-odt=file.odt -o output_file.odt

Using plain text for writing gets a lot easier. You just need to define the styles once and Pandoc will take care of the rest for you. No wonder Pandoc is presented on its homepage as a swiss army knife for working with documents. You can even tell it to generate table of contents based on headings used in the text. The options are vast, just look into the manual man pandoc.

There are few more things I would like to note:

  • The Pandoc manual says that for best results, the style reference files should be generated by Pandoc in the first place.

  • Pandoc recognizes multimarkdown footnotes (for syntax, search for footnotes here) and converts them correctly, yay!

  • If you need to quickly convert Markdown to HTML or PDF, you can always use Dillinger, an online conversion tool.

  • There is also one other way to make the conversion without Pandoc, though I suspect there are less options than are offered by Pandoc.