<<< Date Index >>>     <<< Thread Index >>>

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