Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Christian Neukirchen]

address@hidden writes:

> I am suggesting this exercise only for recreational purposes.
>
> Design MH, from scratch, without the constraints affecting the original
>   MH design.
> Suppose, you weren't designing a system to run on a time shared PDF 1145,
>  but on a
> single user, multi-core system. Suppose that you  had multi gigabyte disks
> available. But also suppose you had to worry about distributed data and
> processing.
> But, mostly importantly, suppose that you didn't have to worry about
> being too radical for acceptance.
>
> What, then. would MH look like?
>
> Here, for example, is one stab at how messages would be stored.
> Each message would be a directory. Each  component would be a  file or
> directory,
> whose name was the component name, Each MIME part would be a directory.

The design of my future mail reader will be as follows: mail is stored
in Maildir (read-only support for Mailboxes is available, too).
Maildir support allows me to use offlineimap to sync against an IMAP store.
However, for reading the *results of query* against the store (for now,
I use mairix for this), such as "all new/unread mail", "all mail
matching $words" etc. will be rendered into trees like this:

idx
cur -> 1/
1/raw -> 
/home/chris/Mail/INBOX/cur/1343755814_1.9959.juno,U=623,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
1/text
2/raw -> 
/home/chris/Mail/INBOX/cur/1343755654_3.9959.juno,U=544,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
2/text
3/raw -> 
/home/chris/Mail/INBOX/cur/1343755143_0.9959.juno,U=131,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
3/text
4/0
4/0/0
4/0/1
4/0/2
4/1
4/musicextras-gui.po -> 0/2
4/musicextras.po -> 0/1
4/raw -> 
/home/chris/Mail/INBOX/cur/1343755102_3.9959.juno,U=89,FMD5=7e33429f656f1e6e9d79b29c3f8

The file "idx" contains the sender and subject data, easily sortable by
various keys (date, from, subject, threaded), as well as the imap flags.
(i.e. like a cache of MH scan(1)).

The "text" contains a rendered version (roughly like mhshow) of the mail
kept in "raw" (for mbox, this is generated, for Maildir, it's just a
symlink).  HTML is rendered with w3m or lynx, for zip files there is a
table of contents etc.

MIME attachments are readily expanded into files (e.g. message 4), so
you can apply patches directly or look at attached pictures.

MH-style tools operate on these trees.  next/prev update the "cur"
symlink to keep track.  Updating message flags like read/replied/trash
directly operate on the Maildir, but also update the rendered tree (yet
tbd).  I'm not yet sure about other sequences (they could be realized as
lists of Maildir files, but then they need to be updated on flag
changes...)

These trees are ephemeral, when I'm done reading them they will be
deleted.  Rendering them is plenty fast, reading is instant (I keep them
in an tmpfs, even).  You can have several trees in different directories
(probably an environment variable will choose the current one, or it
will check if $PWD is one).  You can also render them from procmail or
cron if you really want instant mail reading.

The system is about 2/3 done so far and essentially consists of a <1KLOC
Ruby script (with no foreign dependencies) and a bunch of shell scripts
and aliases.  The mechanic is really simple.

Currently, I'm considering (ab)using vi(m) as an interface for reading
many mails quickly.  vim macros are easy to bind to keys, can run
external commands and show their output, and provide split windows.

I have been thinking about this for years now and tried various other
ideas already.  Please ask if anything is unclear.

-- 
Christian Neukirchen  <address@hidden>  http://chneukirchen.org