Pine provides a setting (in .pinerc) for whether to prompt before purging deleted messages on exit. I thought this was on by default. I use pine and stuff never moves out of my inbox unless I told it to do that. Just to be clear, by inbox I mean /var/mail/$USER, not $HOME/inbox.
I do, however, lose the "new" flag on messages I've read, and there doesn't seem to be a way to reverse that. This is sometimes annoying. It would be even more annoying if I switched between multiple mail clients, of course.
You can (through .pinerc) set arbitrary headers to be added to your outgoing mail. I wonder what would happen if you used that to force a content-type of text/plain. As far as I know all my outgoing mail is plain anyway, but I'll pay more attention the next time I forward something.
There is also an option in .pinerc called "mimetype-search-path", which points to a file that (I gather) specifies MIME types and how to handle them. I've never looked into this, but I'm guessing it would be possible to override pine's handling of HTML via this mechanism. It would be better if it were built in, of course, because HTML-formatted email is evil.
Maybe that option is on by default in some other versions -- I was just running whatever came with Mandrake 6.mumble (which is probably the same as shipped with similarly-numbered versions of Red Hat).
I'll let someone Pine doesn't act evil towards (like maybe someone who actually uses it) do the experiments with forcing the MIME-type. But I'm willing to be a test recipient of email and describe how it arrives.
Even if it hadn't moved all my mail out of /var/spool/mail/dglenn, losing the "New" flag would've been annoying. Less scary, but annoying. I don't understand why there isn't an "exit without making any changes on disk" option.
But as long as I'm griping about MUAs, I wish I knew why the Linux version(s) of /bin/mail don't honor the "editheaders" variable that worked on Xenix 3.x, various flavours of BSD, SunOS, and most other Unices I've used. And neither the Linux version nor the most recent couple of SunOS versions honor "noautombox", which I used to find rather convenient. (Now I have to remember to type "ho *" before I quit-with-changes.) So even my preferred MUA isn't perfect; it just fails to be evil.
Emacs doesn't like me either, but at least it's not sneaky about it.
a couple small notes
I do, however, lose the "new" flag on messages I've read, and there doesn't seem to be a way to reverse that. This is sometimes annoying. It would be even more annoying if I switched between multiple mail clients, of course.
You can (through .pinerc) set arbitrary headers to be added to your outgoing mail. I wonder what would happen if you used that to force a content-type of text/plain. As far as I know all my outgoing mail is plain anyway, but I'll pay more attention the next time I forward something.
There is also an option in .pinerc called "mimetype-search-path", which points to a file that (I gather) specifies MIME types and how to handle them. I've never looked into this, but I'm guessing it would be possible to override pine's handling of HTML via this mechanism. It would be better if it were built in, of course, because HTML-formatted email is evil.
Re: a couple small notes
I'll let someone Pine doesn't act evil towards (like maybe someone who actually uses it) do the experiments with forcing the MIME-type. But I'm willing to be a test recipient of email and describe how it arrives.
Even if it hadn't moved all my mail out of /var/spool/mail/dglenn, losing the "New" flag would've been annoying. Less scary, but annoying. I don't understand why there isn't an "exit without making any changes on disk" option.
But as long as I'm griping about MUAs, I wish I knew why the Linux version(s) of /bin/mail don't honor the "editheaders" variable that worked on Xenix 3.x, various flavours of BSD, SunOS, and most other Unices I've used. And neither the Linux version nor the most recent couple of SunOS versions honor "noautombox", which I used to find rather convenient. (Now I have to remember to type "ho *" before I quit-with-changes.) So even my preferred MUA isn't perfect; it just fails to be evil.
Emacs doesn't like me either, but at least it's not sneaky about it.