On Sat, Feb 02, 2013 at 06:17:10PM +1100, Cameron Simpson wrote: > | Or, to say it another way (from the manual): > | > | <save-message> s save message/attachment to a mailbox/file > | > | ln != save-message. > > ln doesn't change the UI behaviour.
It does, in the sense that IN ONLY SOME CASES, the UI would cause a
different effect than it otherwise would. But regardless, I think
you're missing the main point (which I'm getting to)...
> Just because mbox _forces_ a wasteful copy doesn't imply maildir should
> behave the same way.
I think it does, but regardless, I think the current behavior (sans
auto-deletion) is the ONLY behavior that is sensible. For the TLDR
crowd, I'll respond to the rest of your message first, which mostly
gets the point across, and then provide the lengthy explanation
below...
And it isn't wasteful, if that's what the user actually wanted.
> Speaking for myself, if messages have the same message-id I expect
> them to be essentially equivalent. I don't require them to be
> distinct files/copies.
Then you apparently do not need the save-message feature...
> As remarked elsewhere, mutt's capable of a server-side IMAP move
> message. Nothing says whether that's a copy or a hard link behind the
> scenes.
That is not "save-message"... that is "move-message", which I think
should also exist. In fact, to make the UI most consistent and
logical, this is what you should have:
save-message - copy messages to a file
copy-message - copy messages to a folder, leave the current intact
move-message - copy messages to a folder, IMMEDIATELY remove from
current folder, and DO NOT ASK ME TO CONFIRM DELETION
[There's a problem with the move-message behavior I described, which
since this is already long, I won't go into other than to say it's the
mbox folder sync problem... This also may explain why it does not
currently exist as a separate operation. But it IS solvable... no
other client has this problem AFAIK.]
Now, coming back to this:
> ln doesn't change the UI behaviour. Just because mbox _forces_ a
> wasteful copy doesn't imply maildir should behave the same way.
First, let me say that I believe the reason you have what you have
today is precisely because the mail store was never completely treated
as an abstraction, and is not treated consistently regardless of the
format, as it should be. Instead, the user interface and related
behaviors have always implicitly acknowledged the properties of the
mail store as a file or set of files, depending on what you use. This
historically has been most evident with new mail handling, though
there have been some improvements more recently in that regard (still
a ways to go on that though, but getting it right probably requires
making mutt threaded or doing something even more crazy). Your link()
case only makes this worse, if implemented.
Saving a message to a file is, in practice, the identical operation to
copying the file into an mbox folder, and *almost* the identical
operation to saving it to a maildir folder (there's a small bit of
extra logic to deal with the directory structure). However
conceptually they are distinct, and the UI should acknowledge that
difference, and mutt should behave accordingly. It does not.
The purpose of save-message is to extract a message out of the mail
store abstraction (whatever it may be) and save it *somewhere*... that
somewhere may be another mailbox, OR IT MAY BE A FILE. If it's a
folder, it may be an mbox folder, or it may be... something else.
Out of all the possibilities, the only case where using link() makes
any sense at all is if both the source folder and the target are
maildir folders. But even in that case, if you use ln, you do not
achieve the purpose of the save-message function. You still have one
copy of the message, which just happens to appear to be in two places
on the filesystem. Mutt absolutely should NOT assume this is what you
want, as this does not satisfy the concept of "save-message".
Now, I will grant you, this feature is a bit schizophrenic. It also
assumes that once it has done whatever it's going to do, that you no
longer want the existing copy of the message, and marks it for
deletion. At which point I have to go and undelete it, which I've
always found annoying. Because when I use this feature, I do in fact
want a separate copy of the message. Pretty much always. I suspect
that it behaves this way because ME (I'm assuming) decided that the
two operations, moving a message to another folder, and saving a
message to a file, were functionally equivalent, and therefore elected
for the economy of only implementing one. Trouble is, in neither case
does it really do what the user wants it to do, IMO. What the user
really wants, I believe, are the three behaviors I described above.
--
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.
pgpRUMPr3FWkZ.pgp
Description: PGP signature
