Re: domain-name based mailboxes (OT question about terminology)
On 2009-03-10_14:22:54, Kyle Wheeler wrote:
> 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
No, rudeness is the refuge of the ignorant. You know Mutt. And, are
willing to explain it! You have no need of rudeness ;-)
I do see the need for better terminology. I see particularly that
a need for terminology that works equally well for mbox format and
maildir format. I don't have any suggestions. I recognize that I am
mired in terminological gook. Maybe some day ...
Thanks
--
Paul E Condon
pecondon@xxxxxxxxxxxxxxxx