About Articles Projects Links Apps Feed

mu4e-conversation

Single buffer full-thread display to make e-mails great again!

This package was originally introduced on Reddit.

Introduction

mu4e-conversation is a new e-mail interface built on top of mu4e.

It displays a full thread of e-mails inside one single buffer. This makes for a much more pleasant e-mail experience when reading through threads: the transitions are not only smoother, all Emacs functions apply to the entire thread instead of just to one message (e.g. searching).

As an avid email user, my experience has been night-and-day compared to other interfaces: a never-go-back productivity booster!

See the homepage for screenshots.

mu4e-conversation is packaged for MELPA and Guix.

Features

  • Dual-view: Seemlessly switch between “linear” and “tree” views.
  • The linear view: display the e-mails chronologically in a fashion similar to Magit’s diffs (or Gmail, or your favorite messenger).
  • The tree view: display the thread as an Org document where the Org nodes correspond to the thread nodes. Thus the view retains the structure while displaying all messages at once.
  • Highlight the text of new (unread) e-mails with a dedicated face.
  • Use all Org features from the “tree” view: fold nodes, open links, highlight quotes and code, fold code, etc.
  • In the tree view, the snippets produced by message-mark-inserted-region

    --8<---------------cut here---------------start------------->8---
    foo
    --8<---------------cut here---------------end--------------->8---
    

    are automatically converted to a #+begin_src / #+end_src Org block.

  • Fill long lines with M-q (mu4e’s original feature).
  • Hide cited text with # (the ending quoted text with the signature): this is much smarter than mu4e-view-toggle-hide-cited since it does not hide quoted text in inline answers.
  • Search an entire thread at once (think helm-occur or the Ivy equivalent).
  • View several threads at the same time.
  • Use sender-specific faces, e.g. Alice is in yellow, Bob is in green, you are in white.
  • You can color backgrounds instead of fonts if you’d rather have a more “smartphone messenger” look.
  • Evil Collection bindings.
  • In-buffer replies: it basically allows you to reply to the thread within the buffer itself. Go to the end of the buffer and start writing, then press C-c C-c (mu4e-conversation-send). You can save the draft with C-x C-s (save-buffer). It makes for a decent “messenger” experience and saves some more window/buffer switches.
  • Citations: You can also press RET (mu4e-conversation-cite) on an active region and it will append the corresponding citation to the composition area.

A call for better e-mail interfaces

I believe the reason that e-mails are often looked down upon is mostly due to the overwhelming presence of poorly designed user interfaces.

The “conversation view” feature is vital to most users. I think it’s partly what keep users tied up so loyally to the social media platform of the moment (Facebook, Whatsapp, <insert-the-next-popular-messenger-here>).

Gmail is possibly the most popular e-mail interface and that might be thanks to its feature of something close to a “conversation” view. That said, Gmail thread view is not as convenient (e.g. messages folded by default, lack of controls) and it can’t display a tree view.

Notmuch offers a similar tree view but the implementation is different (it does not use Org mode).

Interestingly, the Nabble mailing list archive offers the same linear and tree views. I don’t think it can be used to display personal mailboxes though.

Most other clients cannot display more than an e-mail at once on screen (tabs are a poor approach to navigate a thread).

The composition area is often detached from the thread.

A brilliant aspect about e-mails is that it does not brandlock users: they are free to save their e-mails anywhere and use the interface of their choice. If we value the freedom to own and control our communication data, I think it’s important to steer away from locked-down platforms and use more open protocols. Making e-mails more attractive would be an important step forward in that direction.

Comments

Date: 2018-08-22

Made with Emacs 27.0.50 (Org mode 9.1.9)

Creative Commons License