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
vim. “Limit” is something I am more used to with the
web client, and it’s what I use the most.
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
Caching mail for faster search
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
message_cachedir variables in your
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.
Limiting code to 80 (or 100 or 120) characters per line. It’s a well-known topic, and there’s an overall consensus on the subject, not counting occasional questions by newbies and odd cases. Most established tech companies have their own line length guidelines. These are often dependent on a language, such as in the case of Google with their 80 character Python and 100 character Java limits.
In this article, I won’t be advocating all the usual arguments, such as easier diff with version control software, or the ability to stack windows side by side on wide screens. No, I believe that battle to be won quite a long time ago, the topic is now closed. But something I didn’t find mentioned in any of the discussions is an interesting point from the world of writers and designers.
Ever since I started being interested in improving my writing skills, I found article after article mention the importance of line length in reading. Interestingly enough, this issue was raised in a world of literature. It had been resolved long before programmers were fascinated with the desire to use up rapidly expanding screen real estate.
I am talking about something known as “measure” in typography. It seems to be the reason newspapers use narrow columns, or books leave such vast margins around the text on a page. Here’s an exempt from the Wikipedia article:
Measure (or sometimes “The Measure”) in typography is the length of a line of text. For a single-column design measure should ideally lie between 40 & 80 characters. Many typographers consider the perfect measure to be 65 characters. If the lines are too short then the text becomes disjointed, if they are too long the content loses rhythm as the reader searches for the start of each line. Punctuation should preferably hang outside the measure.
Most programming languages use special operators and keywords, which can be considered “punctuation”. Some languages are more verbose (use more punctuation), and some aren’t. If you remove punctuation, the 80/100/120 character limit perfectly fits the standard time-honed “measure”.
Maybe I can use this as an additional argument the next time I have to explain to a junior new hire why the character limits are so strictly enforced.
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
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
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
nnoremap <Leader>vr :VimroomToggle<CR>
<Leader>vr to drop in/out of the VimRoom mode (
<Leader is a
\ 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:
- 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.
- 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.
- 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.