-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday, March 10 at 11:58 AM, quoth Paul E Condon:
> So is it correct to say that the difference between a 'folder' and a
> 'mailbox' is that a mailbox is a folder that is checked on occasion
> for the arrival of new mail?
Unfortunately, its not so simple, because these terms are sometimes
used interchangeably, and are used differently in different contexts
(for example, "folder" is sometimes used as a synonym for "directory"
when discussing things that relate to filesystems).
In the context of mutt's configuration, THE $folder value is a
convenient way to shorten how much you have to type to access your
folders. *A* folder (as in "folder-hook" or "change folder") is a
generic way of referring to any place you store email. It could be
more specifically termed "URI-hook", but "folder-hook" is good enough
and somewhat more intuitive. The term "mailbox" is often used as a
synonym for this latter definition "folder", but when being rigorous,
given that the command `mailboxes` tells mutt to check specific
locations for email, it seems to me that "mailbox" ought to be
reserved for just folders/URIs that are checked for email regularly.
Mutt's documentation is *rife* with abuse of the terms "folder" and
"mailbox" such that anyone attempting to learn how email works based
on mutt's documentation is destined for confusion. That's generally
because mutt's documentation was written by lots of different people
with not much in the way of guidelines who were all trying to be brief
rather than precise. It makes sense only if you already know (more or
less) what mutt's doing.
Just as an example, here's the muttrc man page's description of the
$folder setting:
folder
Type: path
Default: "~/Mail"
Specifies the default location of your mailboxes. A "+" or "="
at the beginning of a pathname will be expanded to the value
of this variable. Note that if you change this variable (from
the default) value you need to make sure that the assignment
occurs BEFORE you use "+" or "=" for any other variables since
expansion takes place when handling the "mailboxes" command.
Isn't that just awful prose? The last sentence barely makes sense, and
it uses the term "mailboxes" in a way that only serves to confuse.
Here's what it SHOULD say, if we're being more rigorous about our
vocabulary:
folder
Type: path
Default: "~/Mail"
Used as a shortcut for a frequently-used path prefix. Much
like "~" expands to the value of $HOME when used at the
beginning of a path, "+" or "=" expand to the value of $folder
when used in the same way. Be aware that the expansion happens
when the prefix is interpreted, so set the value of $folder
before using the shortcut (e.g. with the "mailboxes" command).
Also keep in mind that the expansion only occurs when mutt is
expecting a path, not when handling arbitrary strings.
See what I mean?
Here's another example from the muttrc man page:
folder-hook [!]regexp command
When mutt enters a folder which matches regexp (or, when
regexp is preceded by an exclamation mark, does not match
regexp), the given command is executed.
When several folder-hooks match a given mail folder, they are
executed in the order given in the configuration file.
This seems clear enough, until someone asks "My mail is stored in
Maildir format; why doesn't a regexp '*/new' match all new and unread
messages?" Note that the question presumes that *folder* is used in
the sense of "filesystem directory" rather than the URI sense, but
given that the documentation isn't clear which sense of the word
"folder" is being used, it's a perfectly legitimate confusion. Now
imagine someone added a "cd" command to mutt to allow mutt to change
its current path! This has been discussed on the mutt-dev mailing
list. If that were implemented, suddenly this documentation would be
*extremely* confusing. Does a folder-hook trigger after a :cd command
is executed? By the documentation, you would think so! A better way of
writing that entry would be:
folder-hook [!]regexp command
Just before mutt views a mail URI which matches regexp (or,
when regexp is preceded by an exclamation mark, does NOT match
regexp), the given command is executed.
When several folder-hooks match the URI being viewed, they are
executed in the order they were defined.
Unfortunately, by trying to be precise, it begins to sound awkward.
Or how about this one:
mbox-hook [!]pattern mailbox
When mutt changes to a mail folder which matches pattern,
mailbox will be used as the "mbox" folder, i.e., read messages
will be moved to that folder when the mail folder is left.
The first matching mbox-hook applies.
Note that "mailbox" and "mail folder" and "folder" are all used
interchangeably! Why? I have no idea. But if we get pedantic, things
begin to get even more awkward:
mbox-hook [!]pattern mailURI
When mutt views a mail URI which matches pattern, the
specified mailURI will be used as the $mbox setting, i.e.,
read messages will be moved to that URI when mutt either quits
or views a different mail URI.
The first matching mbox-hook applies.
See what I mean? First we've got the confusion about terms for
"folders/mailboxes/URIs", which could be filesystem directories, URIs
that specify a canonical name for a location that stores email, or
URIs that specify a canonical name for a location that stores email
that is checked periodically for new messages. And then there's the
potential confusion over what "entering" and "leaving" means. For
example, when you go to attach a file to a message you're sending, and
you cause mutt to bring up the "browser" interface, are you "viewing"
those "folders"? Are you "entering" them? Why are these terms the same
ones we use for when we're reading email and "viewing" email
"folders"? It's an ugly mess of confusion.
And then, of course, we have the `mailboxes` command, which is used to
specify a list of mail URIs to periodically check for new messages.
This command (unfortunately) thereby reserves the term "mailbox" to
refer only to URIs that are being monitored, which is unfortunate. It
would be clearer if the command were renamed `monitor`, because then
not only would the purpose of the command be obvious, but we could
then re-use the term "mailbox" as a less-awkward synonym of "mail
URI". Consider the difference in clarity:
mailboxes filename [ filename ... ]
unmailboxes [ * | filename ... ]
The mailboxes specifies folders which can receive mail and
which will be checked for new messages. When changing folders,
pressing space will cycle through folders with new mail. The
unmailboxes command is used to remove a file name from the
list of folders which can receive mail. If "*" is specified as
the file name, the list is emptied.
...versus:
monitor mailbox [ mailbox ... ]
unmonitor [ * | mailbox ... ]
The monitor command specifies mailboxes that will be checked
periodically for new messages. After triggering the
<change-folder> command, pressing space will cycle through the
set of mailboxes with new messages. The unmonitor command is
used to remove a mailbox from the list of mailboxes being
monitored. If "*" is specified, the list is emptied.
You can tell that the original language was written once upon a time
when the only type of email storage that mutt understood was
mbox-formatted files ("filename"?!? HA!). These days it only serves to
confuse.
Of course, this confusion doesn't help when someone (like the OP) asks
a question and intends to use a term (like "mailboxes") in a specific
sense, but doesn't give a clear indication of what that sense is.
Consider: what did the OP mean by "mailbox"? What does it mean to "set
up" a mailbox, and which of the possible interpretations of that word
makes sense in that context? Really, the only possible definition of
the word that is *set up* (i.e. "defined" in advance of using it) is
the sense based on using the `mailboxes` command, so presumably that's
what the OP meant. But... the OP's question doesn't make sense when we
think about it that way since, as I said in my reply to him, a mailbox
(used in the URI-that-is-checked-periodically sense) is defined by the
URI, which contains both the username (UID) and the server (domain).
So how should we interpret his question? The only way that the
question *does* make some sense (to me) is if he's setting up
mailboxes for *delivery*, e.g. via an MTA or via procmail. Perhaps he
thinks that mutt behaves like procmail when it fetches mail and that
it filters messages into folders? That's a common misconception among
people who have never used mutt before. But he also seems to indicate
that he knows something about mutt's limitations, since he makes
reference to some "normal" way that these mailboxes are set up...
which doesn't make any sense either. Do you see what I mean?
Perhaps I should have just rudely referred him to a "how to ask good
questions on a mailing list" webpage. But I'm hoping that the way I
did respond is more useful for him.
~Kyle
- --
To invent, you need a good imagination and a pile of junk.
-- Thomas Jefferson
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iEYEARECAAYFAkm2vg4ACgkQBkIOoMqOI15ABQCgjR7y1ZZ5E3Zvbuk+PyABiLgv
OlsAnAw2pmLZQyAdqSHdqqxs6VThk0Mw
=pOjQ
-----END PGP SIGNATURE-----
