Tag Archives: evolution

Using the GNOME Evolution address book with Mutt

For a while I’ve been using the GNOME Evolution address book with Mutt, my favorite email client. I use a script called mutt-eds-query, which consults the default evolution-data-server (EDS) address book to find contacts whose name or email address match a substring. I have a couple thousand contacts still stored in my EDS address book, so it’s really useful for me to be able to consult them. When I type an address in Mutt’s To: field, for example, I give a few letters and then hit Ctrl+T to see a list of completions.

Unfortunately, the script stopped working when I moved to Fedora 18, because the new release contains the newest Evolution and EDS (3.6 versions). The new EDS cleans up a number of deprecated functions and has a more regular interface for querying data sources. Obviously that means the mutt-eds-query needed changing too. I used the extensive GNOME developer documentation to find out what had changed, and updated the script I found on the Mutt wiki.

So I hacked in some changes today. I’m not a born C programmer, so I’m sure there are bad style uses and other stupidities in what I did. Nevertheless, I posted the results alongside the original on the Mutt wiki page. I’ve also put my files up on my Fedora People space. Feel free to grab and try it, and let me know if it helps you. (You’ll need the evolution-data-server development libraries to compile it.)

In the future I’d like to update this script to aggregate and query my GNOME online accounts as well. There’s a very robust set of functions for doing that, and documentation, so if I could just find the spare cycles, I think I could probably make this happen. Alternately, I wonder if that might make a good addition to the folks-tools package?

Is your heart fonder?

That’s the longest break I’ve ever taken from blogging: 36 days without a post. At first I was just too busy for a week. Then as time went on, I had more and more things I was thinking about blogging — the pile of ideas kept getting bigger. Finally the sheer size of the pile and number of possible choices became overwhelming. I was a victim of too many choices.

I decided to break the stalemate by putting aside all of the ideas and starting with one new one, which is to talk about the tools I use to be more efficient and productive at work. What I use might not be right for everyone, but perhaps you’ll see some idea here that can help you with your job or your hobby, and be happier with your effectiveness. I was inspired by John Poelstra’s recent post on The Drug of Distraction to write about this subject.

Inbox hell. Note this is not my actual desk or inbox.

Email is the lifeblood of most information-oriented jobs now, and especially one revolving around open source or a globally dispersed company. Both of these characteristics are part of life at Red Hat, of course! It’s really important to have a way of dealing with email that makes your work more efficient. For me that comes down to two major considerations. There are others, of course, but they’re not quite as important as getting these two right. That’s my email client, and filtering.

First is your email client. For a long time I was a relatively happy user of Evolution, the GNOME personal information manager that helps you manage email, calendar, tasks, and addresses. It’s a robust, full-featured program and I still think it’s a wonderful piece of work even if it has its issues. And honestly, what software doesn’t? However, what I found was that there were a couple of factors that were causing me to lose a lot of time in reading and processing email. By “processing,” I mean performing whatever task is appropriate for a specific piece of email. That might mean deletion, or it might mean responding immediately, or something in between.

Evolution allowed me to have several windows open at once where I could be drafting many different emails. I could make a start, then put the compose window aside to work on something else, or process another more important email before finishing. And for me, that turned out to be a drawback. It encouraged a lack of focus on what I was doing, so that by the end of the day I had a bunch of unfinished responses — and the concomitant feeling that I was a failure because I wasn’t getting the responses out. I was letting my tool usage affect not only my output, but the way I felt about my performance!

(You could of course say that the fault here was mine, not my email application. After all, why can’t I just focus better? And that would be a perfectly fair assessment. However, to change very deeply ingrained behavior takes a lot of time and effort, which I felt I could better spend simply doing work. And it’s probably arguable that changing my behavioral reaction to a windowed environment to optimize for how I deal with email at work wouldn’t necessarily be a net benefit in the general case of my overall computer usage. In any case, I don’t want this to come off as an indictment of Evolution, which I think is a great piece of software.)

Another factor that was hampering me was the way I was accessing my email through the client — IMAP in this case. Each time I wanted to read or reply to email, I was hitting the network. I have a great broadband connection at home using Cox Cable — around 10-12 Mbps downstream and something like 2 Mbps upstream. But even so, latency delays (seek and retrieval) on the server is more of a concern than transmission time, and there was a delay of seconds every time I accessed email. And with hundreds of email messages a day I was looking at — after filtering those I didn’t need to read — I was wasting a lot of time. With 500 email messages and, say, 3 seconds per email on a good network day between retrieval and response (this is a conservative estimate), I was losing 25 minutes a day assuming response time was good. Over the course of a week, that’s over two hours!

Two tools helped me wrangle my email to the point where I could reclaim every bit of those two hours and more. First was the Mutt email client, which is a text-based email reader. Like most text based programs, it has a bunch of keystrokes that you have to learn if you want to use it quickly. It took me about three days of use to get really accustomed to its interface, and most of two weeks to optimize my configuration. But once that was finished, I had conquered the focus problem in dealing with a GUI-based, windowing email client. I was responding to an email in a terminal as a single foreground operation, and when I was finished with my response, I would send it to return to the mail reader. Not seeing other email messages waiting for me (or arriving) as I composed helped me focus on the task at hand, finish it quickly, and return to processing other mail if needed.

The second tool — or rather a combination of tools — that helped me immensely was offlineimap, for syncing email to local storage, and postfix for sending out email from my local system. Using this toolset meant that my network delays were a thing of the past. Recalling email from its stored location is instantaneous, and when I send an email, the response from the server is instantaneous as well. The email gets sent out as a background operation and if anything untoward occurs I get notified as with any other email service.

The other major benefit of offlineimap is like other integrated clients in that it gives me a choice of when to sync my mail. I can either run the synchronization as a periodic background process, or as a one-time operation. I’ve come to greatly prefer doing this as a one-time operation because it keeps me from “riding my Inbox” all day. Nothing will kill true productivity faster than being on email all day, waiting for that next “important” message to arrive. Instead, I try to check email only a few times each day: (1) all mail in the morning after completing any other critical work; (2) important folders only, right before lunch; (3) important folders only, as an afternoon break and limited to no more than a specific time like 10 minutes; and (4) (optional) remaining mail before I leave for the day. This type of routine has helped me restrict my email processing time per day to a very reasonable amount of time — leaving me more time for work requiring heavy focus, deep thought, in-person contact, and/or dedicated writing or composition.

The second consideration for email was filtering. Server side filters are the most effective in my opinion, because among other benefits they don’t rely on me having the same local configuration wherever I’m retrieving or processing email. I have a lot of filters in place both with my GMail account and my internal Red Hat email, to sort each list separately, and prioritize specific kinds of mail such as those that come directly to me from specific people (like my manager).

These filters help me prioritize my email work, so that I don’t end up spending an amount of time on each list proportional to its list traffic. Certain lists, and of course my direct Inbox, are more important to me, and I handle those first. If I’m pressed for time I can defer all the rest. In addition my Mutt email client helps with this process because I have a routine to elevate specific mailboxes to the top of the list through which I cycle. I also practice judicious use of functions such as “mark thread as read,” avoiding spending too much time on discussions that don’t require my attention or input. Every six months or so I also make a practice of archiving old mail so that my mailbox searches, which usually are focused on the recent past, stay fast.

More generally, using this combination of tools and routine helped me conquer an internal focus problem as well as an external latency problem. Again, while my choices may not be right for everyone, they really helped me.