On Fri, Jul 17, 2009 at 02:03:44PM -0600, lee wrote: > > A big part of the problem is that you're apparetnly trying to use > > Mutt through its file browser interface... this is not how Mutt is > > intended to be used, and yes, it's clunky: Mutt is not a file > > manager. > > No, I was looking for a better way to organize mails. Using more > folders to store mail in them isn't a good way for me to do that. You > agree that mutt gets "clunky" when you try to do that.
No, I do not agree to any such thing. It gets clunky when you try to
manage arbitrary folders that you're creating and removing on the fly,
and not telling Mutt to watch with the mailboxes command. But I
manage 47 folders in my "home" configuration of Mutt, and considerably
more than that at work, and I just don't have the problems you seem to
have. I don't find it clunky at all.
> > But it doesn't matter! Because you just tell mutt about them with the
> > mailboxes command, and the location becomes not interesting. The
> > folder browser prevents you with a flat view of all your mailboxes
> > that you've told Mutt about. You keep insisting that Mutt is clunky
> > and won't do what you want it to, but you haven't even tried to use
> > Mutt the way it's intended to be used. What do you expect?
>
> It isn't very flexible to use it that way. Every time you would create
> a new folder to simulate a category or remove a folder, you would have
> to edit the config again.
Have you ever considered that the arrangement of categories you're
selecting is just too complicated? You can either choose your
categories carefully, perhaps somewhat broadly, so that you never (or
at least very rarely) need to add or remove any folders... or you can
do what you're doing. But we already know that the latter is not
working out for you... ;-)
One wonders what kind of e-mail you're receiving that you need to have
so many categories... Let's use your accountant analogy, actually. I
think it was not a very good analogy to make your point, but I think
it makes mine rather well. Suppose you have a room with a bunch of
file cabinets for your bills. The room is full -- there are no more
places to put file cabinets. The cabinets are full of folders -- your
boss will not let you buy more, because you have exceeded your budget
for new folders for the year. You get a bill that doesn't fit into
one of the folders you already have...
What do you do?
> Removing folders is not supported, renaming them isn't either.
Mutt can only do either of those operations safely if all of the
follwing are true:
1) No mail is being delivered to the folder in question.
2) The new name chosen is on the same physical device and partition
as the current one.
3) #2 also applies for deletes, because deleting a directory is not
an atomic operation, so you need to rename the directory first.
Mutt can never reliably determine #1. Mutt often can not determine
the others (e.g. if they are on a network filesystem or remote server,
such as IMAP). It is therefore never reliably safe for mutt to do
this, and can not be made so. But if you add the feature to Mutt,
people will use it, even if you tell them it's not safe, and some
people will lose mail, and complain. So, if you're a Mutt maintainer,
you've got to be crazy to add a feature like this.
Both operations can only be done safely with one-file-per-folder
formats. The assumption here though is that the user is having mail
delivered into multiple maildir folders, not managing them entirely
manually as you are doing. This *must* be the assumption, because a)
this is how maildir was intended to be used (it's actually the reason
it was designed) and b) because this is how the overwhelming majority
of Mutt users (and maildir users) manage their mail.
The proof of b) is that Mutt offers essentially no other way to do it;
various people have hacked things around and on top of Mutt to do some
different things, like the category threads trick; but such tricks are
not mainstream. And if you don't believe me about a), read it in Dan
J. Bernstien's own words (he's the creator of Maildir):
http://cr.yp.to/proto/maildir.html
Why should I use maildir?
Two words: no locks. An MUA can read and delete messages WHILE NEW
MAIL IS BEING DELIVERED: each message is stored in a separate file
with a unique name, so it isn't affected by operations on other
messages. [Emphasis added by me.]
Deleting mail folders was never a consideration... there's very little
reason to delete folders to which you're actively having mail
delivered. Being unable to safely delete maildirs is one of the
drawbacks to using maildir, but for most users, it is a total
non-issue. The people in charge of the Mutt code know that, if the
user is not paying attention and requests this by mistake or without
thinking about it, and the folder you do it to is one you're actively
having mail delivered to, doing this will pretty much guarantee that
you will lose mail. It is not a safe feature to put in Mutt. Period.
> > So put your folders in your config. This is the way Mutt is intended
> > to be used. You can even do it programatically, by, for example,
> > writing a script to identify maildirs in a particular directory tree,
> > and output mailboxes commands for each one it finds. Moreover, if you
> > stop mixing directories and maildirs, you could even use the file
> > browser... though again, that's not how Mutt is intended to be used,
> > so you're giving up a lot of the power of Mutt if you use it that way.
>
> Well, are you now saying that mutt is supposed to be used with only
> one mail folder?
Eh? I think there may be some language barrier here... I'm not sure
how "put your folders [<- note the plural "folders"] in your config"
got interpreted as "use only one folder..." They're not even close.
> > Because a maildir IS a directory, and it's not possible to reliably
> > determine the difference. You can make an assumption that if a
> > directory has cur/ new/ tmp/ in it, it's a maildir, but that may not
> > be the case. And a directory might have some of those, but not all of
> > them, and be an actual maildir. Or it might not be. And moreover,
> > it's because Mutt expects you to tell it about the mail folders you
> > care about. In so doing, it prevents a lot of tedious guesswork that
> > mutt could get wrong, in determining what your mail folders are.
>
> Ok, that makes some sense. Still it could show me what is what after I
> tell it which folders are a maildir.
It does. If you specify them with mailboxes, they're listed
separately in one of the file browser screens from any other files in
your directory tree.
> Since you need to tell mutt which folders are maildirs, why can't you
> tag directories in the directory list to tell mutt that those are
> maildirs and have mutt write that into its config? Why doesn't mutt
> optionally ask you when creating a new maildir if you want to add the
> new directory to your mailboxes?
Because Mutt does not itself update your configuration. Ever. The
only thing resembling updating your config that it does is allow you
to append e-mail aliases to a specified aliases file. However, it's
generally expected that this file is not your config file, and that
you must edit your config file manually to have Mutt source that file.
Mutt expects that you will manually maintain your configuration.
Now, if you think that's a weakness in Mutt, I would generally agree.
But it's consistent about not updating your config, for this reason,
or any other.
> > How could managing your mail this way possibly be efficient or
> > productive? You're creating folders on the fly and deleting them
> > when they're empty.
>
> I'm not saying it's efficient or productive --- I'm saying all the
> time it's not while you kept suggesting that I do it that way. Maybe
> that was a misunderstanding?
What I'm suggesting is that you stop trying to associate arbitrary
categories with each e-mail, and create well-defined categories, and
stick to them. If you can do that (and I'm positive that you can, if
you just give it some thought), most of your problem vanishes. Then,
if you read up in the manual about the interface issues that are
leading you to describe Mutt as awkward, most of the rest of your
problems also vanish.
> > Yeah, do that. Create folders with broad characterizations, and keep
> > them fixed; don't create new ones, and don't delete them. It won't be
> > a problem to find mails in such folders if you know what you're
> > looking for; Mutt has very powerful searching facilities.
>
> Yeah, that's what I'm doing, and it always has been insufficient for
> organizing mail. How could managing my mail like that possibly be
> efficient or productive?
It seems to work well for millions of Internet users...
> > Most of your issues with Mutt boil down to you not using Mutt and
> > maildirs as they were intended to be used.
>
> I don't see what you mean. On the one hand you suggest that I use
> folders to simulate categories; on the other hand you suggest that I
> shouldn't do that because mutt and maildir aren't supposed to be used
> like that.
I'm not saying that at all, quite the opposite. Mail folders
ARE categories. I'm saying you already have what you want.
I'll try to summarize the issues you've specifically complained about.
In the list below, substitute "category" for "folder" as you see fit:
1. Mutt does not make it easy for you to create new folders
2. Mutt does not make it easy for you to delete folders
3. Mutt does not make it easy for you to move mail between folders
4. Mutt does not make it easy for you to change to a different folder
5. Mutt does not make it easy for you to see mails in multiple
folders at the same time
Now, I'll try to address each one as succinctly as possible.
1. This is false, especially since you want to do this in the context
of moving a message into a new "category" (folder). Press 's' to
(S)ave the message. Mutt prompts you for the folder (category) you
want to save it in. If the folder exists, press '?' to get the
list, and then select it either using the arrow keys, or typing the
number. If the list is too long, you can even search for the
folder by pressing the '/' key, and typing a pattern to match.
If you keep all of your categories (sorry, I meant folders) in
$folder (and you've set that variable appropriately in your
.muttrc), they will all appear in the list that mutt presents, even
if you don't use the mailboxes command. If you want to use a
folder heirarchy, and you tell mutt about all of your mailboxes
using that command, hit tab to get that list of folders (personally
I think this order should be reversed, but whatever, it's only one
extra keystroke). Best of all, you can tell mutt to sort your
categories (er, folders) alphabetically, by date created, etc.
It's very flexible.
If the folder does not already exist, simply type its name. What
could be simpler?
Note that officially, maildir does not support subfolders (mail
folders inside other mail folders)... it may or may not work in
Mutt, I haven't tried.
2. I already explained why this is not possible. But, if you're using
Mutt and maildir the way they are expected to be used, this really
should be a non-issue.
3. The answer for this is exactly the same as #1.
4. The answer for this is exactly the same as #1, except press 'c' to
change folder instead of 's' to save the message... naturally you
can not create mail folders this way.
5. Yeah, Mutt doesn't do this; but I don't know of any mail client
that does.
If you still insist that this can't work for you, then I ask you to
consider that it does work very well for just about everyone who uses
e-mail anywhere. Ask yourself, why not you? Please bear in mind, I
am actually trying to help you do what you need to do. I'm not trying
to criticize your ideas about improving Mutt's interface... I think
some of your ideas are fine -- they're just not how Mutt works today,
and I'd venture a guess that it won't any time soon.
If this doesn't help you, then I'm pretty sure I'm not capable of
helping you, so I bow out at this point.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpz6YzXYqFIo.pgp
Description: PGP signature
