On Thu, Sep 03, 2009 at 03:02:47PM -0700, George Davidovich wrote:
> > So that when I clicked on a link such as:
> >
> > ============================================================
> > <a href="file://localhost/e:/foo/bar.mbox">Foobar</a>
> > ============================================================
> >
> > in Firefox, it would run mutt, opening the mailbox bar.mbox. It
> > was fantastic!
>
> If you say so. ;-)
Computer-wise, I grew up reading mail with
/usr/ucb/mail -f mbox
where "mbox" was a file in the "mbox" format.
I have never really recovered from my indignation at seeing
email clients (as far as I can tell, _all_ email clients after
elm except for mutt and pine) move away from using the mbox
format natively, then hide the email -- now in a proprietary
format! -- deep in an application directory! on C: drive! at
a location with spaces in the pathname!
I do most of my work in CLI (command-line interface) because I
find it more efficient and straightforward than GUI.
If I am reading an important thread in mutt and need to put that
thread into my to-do list, I save it as a file, e.g.:
2009-09-03.mutt-rxvt-configuration.mbox
I run a shell script to add a reference to that file to the
to-do list in my browser, e.g. the clickable:
<a href="file://localhost/e:/foo/2009-09-03.mutt-rxvt-configuration.mbox">
I can move email files around just like any another
data .doc or .xls files, and I can archive the email for a
project together with all the other data files.
I may be missing something, but I don't see any advantages to the
dominant paradigm of email applications with special data formats in
exotic locations.
This being a mutt list, I may be preaching to the converted, but
out of all the articles and documents I have read about mutt, I
do not recall ever seeing an emphasis on mutt's obvious and
crucial advantage for opening and manipulating email files
directly, maybe even from the command line.
Tom
--
Tom Baker <[email protected]>
