Emacs | Raul Benencia

Org Tempus

Mon, 01 Jun 2026 08:23:41 -0300

Time management is a tricky business. Ideally we should spend our precious time in Earth doing things that we’re interested in for as long as we want. Unfortunately that’s not how the life of a modern human works. We have responsibilities, chores, busy work, etc. We have activities that we enjoy doing, and tasks that we have to get over, and ideally we should make progress in all of them. We’re in a constant state of context switching. Additionally, we need to take regular breaks to ensure our brain is not overly engaged.

As an Emacser, I’m an avid user of Org Mode. I find it essential to keep track of my perennial list of tasks, both personal and at work. Org has a handy clocking feature that allows you to track the time you spent on each task. This feature is essential to ensure I don’t overwork, or underwork, in any of my responsibilities. However, it’s a bit of a hassle to clock in and clock out all the time, particularly if you take regular breaks.

Enter Org Tempus, an Emacs package I’ve written on top of Org Mode to automate many parts of my workflow. In particular, Org Tempus allows setting up a default task to auto clock-in when activity is detected in the workstation. This default task is how I track administrative work: catching up with emails, messages, and capturing new work items. How “activity” is detected is configurable and extendable: it can be activity coming from Emacs itself, or activity coming from a desktop environment such as GNOME. The package also permits setting intervals for breaks (similar to the Pomodoro technique) and total worked time, and sends notifications when the thresholds are reached.

Overall, Org Tempus has enabled me to be more intentional with how I spend my computing time. Check the README for the full list of features. I’ve just released version 0.0.2.

Emacs server, systemd and XAUTHORITY

Tue, 30 May 2023 00:00:00 +0000

Running Emacs as a systemd service should be relatively straightforward if using its Debian package, given that it comes with a systemd unit.

Here’s a fragment:

$ cat /usr/lib/systemd/user/emacs.service | head -n7
[Unit]
Description=Emacs text editor
Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/

[Service]
Type=notify
ExecStart=/usr/bin/emacs --fg-daemon

However, I’ve faced the following problem: when running emacsclient from a graphical interface, nothing happened, and it was not clear what to do next.

To unravel these kind of problems, we should always start by checking the logs. An interesting line showed up:

$ journalctl  --user -u emacs.service
...
May 18 16:51:51 zorzal emacs[1308]: Authorization required, but no authorization protocol specified
...

After some digging, I realized this happens because the Emacs server was started before the XAUTHORITY variable was set, and we need that variable to communicate with the display server.

A quick search didn’t show a straightforward or clean solution. Remediating this problem should be relatively simple: we just need to instruct systemd to start the Emacs server after the graphical session. systemd comes preloaded with a special target that can be used for this purpose: graphical-session.target.

A systemd drop-in file can be used to establish this dependency:

$ cat ~/.config/systemd/user/emacs.service.d/override.conf
[Unit]
Requires=graphical-session.target

To pick-up the override, we must remember to run: systemd --user daemon-reload.

Why isn’t this a default in the shipped unit file? I suppose we can’t assume the user will always have a graphical session when launching an Emacs server, so it wouldn’t be safe to make it a default.

Using notmuch-emacs along with other folder-based MUA

Wed, 24 Jun 2015 00:00:00 +0000

I’ve started to leave my mutt niche in order to start using notmuch-emacs MUA. All in all, I can see the see the speed advantage of using notmuch, among other little perks. Nevertheless, the approach of tagging emails instead of organizing them in IMAP folders makes the use of notmuch a little non-portable for others folder based user agents. I wouldn’t mind that, but I like receiving my emails on my mobile phone and as far as I know there is no such thing as a mobile notmuch MUA.

In this blog post I’ll share my approach for using a notmuch based agent, as notmuch-emacs, along with other folder based agents, as Thunderbird or K-9 Mail. The first thing to do is to define the layout of our IMAP folders. In our examples we’ll use something like this:

$ ls -1 ~/Maildir
archive
cur
debian
debian.devel
debian.haskell
debian.haskell.commits
debian.haskell.maintainers
debian.haskell.maintainers.junk
debian.misc
debian.project
new
tmp

So, here I have my inbox folder along with an archive maildir and a hierarchy of folders containing Debian mailing lists. In my folder based mobile agent, K-9, I won’t be bothered with notifications of new mailing list emails, as the agent is configured to only check for new emails in the inbox folder. On the other hand, in a default notmuch setup each time I run notmuch new the database will be filled with all the emails in all the folders and will tag the new ones with inbox. Now, when I’m using notmuch-emacs, I like that my inbox emails be only the ones in my inbox folder. Besides, I’ll also like to add a tag that matches the name of the folder the email is in. In notmuch language:

#!/bin/sh

notmuch new

notmuch tag +archive -inbox "path:archive/**"
notmuch tag +debian -inbox "path:debian/**"
notmuch tag +debian-devel -inbox "path:debian.devel/**"
notmuch tag +debian-project -inbox "path:debian.project/**"
notmuch tag +debian-haskell -inbox "path:debian.haskell/**"
notmuch tag +debian-haskell-commits -inbox "path:debian.haskell.commits/**"
notmuch tag +debian-haskell-maintainers -inbox "path:debian.haskell.maintainers/**"
notmuch tag +debian-haskell-maintainers-junk -inbox -unread "path:debian.haskell.maintainers.junk/**"
notmuch tag +debian-misc -inbox "path:debian.misc/**"

With this method we can use a folder based approach with notmuch tags. Let’s move to another topic. In the notmuch world, archiving an email means removing the inbox tag. If we only do this, all the archived emails will still be in our inbox folder, so what we’ll like to do is to move to the archive folder all the emails from the inbox folder that don’t have the inbox tag. In other words:

function archive() {
    if [ $# -ne 2 ]; then
       echo "Incorrent parameters. Send INBOX and ARCHIVE"
       return 1
    fi

    for e in $(notmuch search --output=files "path:$1/**" and not tag:inbox); do
        mv $e $2
    done

    return 0
}

archive cur ${MAILDIR}/archive/cur

Finally, one little detail is left: spam. In a folder based agent, we’ll usually have a spam folder. In the notmuch world, when we tag an email with spam, a decent client won’t show it in the results of notmuch searches, but it will remain in the folder it was found. So, what we have to do is to move all the spam tagged email to our spam folder.

for e in $(notmuch search --output=files tag:spam and not "path:spam/**"); do
    mv $e $MAILDIR/spam/cur
done

So, if we cron this little script we’ll be able to use a notmuch based MUA along with an IMAP folder based one. Enjoy!