• đź“… Feb 5, 2015 🏷️ Vim

    Custom templates in vimwiki

    I got myself into a habit of using vimwiki for the past year: it helps me to keep track of random bits of information, work and project notes, as well as daily goals and achievements. You can read more about vimwiki in an article I wrote a while back: “Personal wiki with vimwiki”.

    HTML page generated by vimwiki with a custom navigation bar.

    One of vimwiki’s features I really like is an ability to convert whole wiki to HTML with a single command: :VimwikiAll2HTML. There is one annoyance though: HTML vimwiki pages don’t have any navigation elements: the only way to navigate between pages is by clicking through links within a page or using browser’s “back” button.

    Luckily, vimwiki has a setting which allows using custom templates for generating HTML. Assuming your wiki is in $HOME/Dropbox/wiki (can be anywhere else though), make following changes to your .vimrc:

    let g:vimwiki_list = [{
  \ 'path': '$HOME/Dropbox/wiki',
  \ 'template_path': '$HOME/Dropbox/wiki/templates',
  \ 'template_default': 'default',
  \ 'template_ext': '.html'}]

    After that, create a $HOME/Dropbox/wiki/templates/default.html using vimwiki/autoload/vimwiki/default.tpl as a base. I added simple navigation bar to my default template:

    <html>
<head>
	<link rel="Stylesheet" type="text/css" href="%root_path%style.css" />
	<title>%title%</title>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
	<a href="%root_path%index.html">Index</a> |
	<a href="%root_path%diary/diary.html">Diary</a>
	<hr>
	<div class="content">
	%content%
	</div>
</body>
</html>

    Now it’s much easier to jump between wiki entries. Of course, customization doesn’t end there: you can change styles, add JavaScript and make your wiki all fancy and advanced.

    If you’d like to get even better about using Vim, I wrote a book about it: Mastering Vim. I’m pretty proud of how it turned out, and I hope you like it too.

  • đź“… Dec 17, 2014 🏷️ Programming

    Contributing to an existing Octopress blog

    I had to download my Octopress blog to a new machine today and the process of setting up didn’t go as smoothly as I expected. At the end of the day the setup turned out to be simple, and here are the steps:

    git clone -b source https://github.com/username/username.github.io myblog
cd myblog
git clone https://github.com/username/username.github.io _deploy
bundle install

    In a nutshell, you have to manually add _deploy folder set to track master branch of your Octopress repository. Otherwise rake deploy command fails.

    Happy writing!

  • đź“… Oct 29, 2014 🏷️ Writing

    750 words a day

    I’ve had increased interest in writing throughout this year. In addition to being a pleasant and fulfilling activity, it shown a number of benefits in my everyday life and career:

    • Composing emails became faster and easier. When you have to reply to a couple of dozen emails a day, speed and attention to details matters. Writing more taught me to write more concise emails which are easy to read.
    • Writing a lot isn’t a problem anymore. If I have to write documentation, comment code, or just put together a very long email - I’m not put off by the idea. I’m excited about it.
    • Typing speed went up. I already touch type, and constant writing practice increases the acquired speed. Fast typing makes life easier, speeding up mundane tasks, freeing up brain power for more costly activities.
    • It’s easy to keep a condensed work log to highlight the issues of the day. Tough programming issues, “Eureka!” moments, meeting notes - this historical data saved me hours or even days of repeating my mistakes.

    A while ago, I’ve heard of a thing called “750 words”, a site built around a challenge to write 750 words a day in order to improve writing skills and unleash creativity. This looked like a great idea, and I decided to give it a shot. I prefer to keep my personal entries offline, and I decided not to use the provided service, but to keep a set of plain text files on my local machine. Which worked out just fine. It’s all just text after all.

    I lasted for 10 days in a row, which I am proud of (filling up approximately 3 pages a day was no easy task for me). I started of with silly entries about not knowing what to write about, and finished with a piece of a fiction story. That’s a considerable improvement.

    By the end of the challenge I was mentally exhausted. But it taught me a very important lesson: the more you write, the better you become. And that’s one of the main reasons I keep crafting new entries for this blog.

    This happened half a year ago, I just never got around to writing about it. I will go ahead and start another 750 words spree today. Maybe this time I’ll be able to make it last for the whole month.

  • đź“… Sep 21, 2014 🏷️ Productivity · CLI

    Beyond grep

    I search for things a lot, especially in my code. Or even worse - someone else’s code. For years grep served as an amazing tool for this: fast, simple, and yet powerful. That was until I discovered ack for myself. An incredibly easy to use grep implementation built to work with large (or not really) code trees.

    A lot can be said to enforce superiority of ack over grep when it comes to working with code, and it’s all said here: ack’s features.

    Amazing thing is - ack doesn’t even need a tutorial. Learning progression is natural and “just happens” by researching necessary use cases as the need arises (ack has a great manual entry).

    Here’s a typical use example for ack:

    ack --shell 'gr[ae]y'

    Searches all shell script files in the current code tree for any occurrences of “gray” or “grey”. It will search .sh, .zsh, and just about dot-anything; ack will even check shebang lines for you.

    Ease of use, the fact that it’s ready to use out of the box, extensive file types, native support for Perl’s regular expressions: ack does really good job at searching through code.

    Download it from Beyond grep.

  • đź“… Aug 2, 2014 🏷️ Productivity · CLI

    Effective search with Mutt

    I generally don’t use Mutt for everyday emails - I find smooth non-monospace fonts to be more pleasant to the eye, and the visualization my browser offers is hard to beat. The main use-case for me is composing long emails: Mutt lets me use my favorite text editor, which speeds up the editing of long and carefully composed responses.

    Recently I added a new use-case to my work flow: searching through emails. Mutt has a powerful built-in regular-expressions engine, which is something the web Gmail client is missing.

    Mutt has two ways of finding things: search and limit. “Search” just jumps from one matching letter to another, something along the lines what / command does in less, more, or vim. “Limit” is something I am more used to with the web client, and it’s what I use the most.

    Using limits

    Limit works the way regular search works in Gmail: it limits the view to conversations matching the query. Hit l, and enter a search query.

    By default, Mutt will only search through the subject lines, but this behaviour can be changed by prefixing the command with a special identifier. For instance, searching for ~b oranges will limit the view to all the messages which mention “oranges” in the message body. Here are a couple I use the most:

    • ~b – Search in the message body.
    • ~B – Search in the whole message.
    • ~f – Message originated from the user.
    • ~Q – Messages which have been replied to.

    You can find full list in the Mutt Advanced Usage Manual.

    Patterns can be chained to produce narrower results: ~f joe ~B apples. This will search for a message mentioning “apples” coming from an author whose name contains “joe”.

    You may find that searching whole messages is slow, especially if you have more than a couple hundred messages to search through. That’s because by default Mutt does not store messages for local use. This can be changed by specifying header_cache and message_cachedir variables in your .muttrc file:

    set header_cache     = "$HOME/Mail"
set message_cachedir = "$HOME/Mail"

    Now, after you perform your first search, it will cache every message you open, making all the consecutive searches lightning fast.

    Oh, and keep in mind, Mutt stores messages and headers in plain text, so make sure the cache directory is not shared with anyone but yourself.