I'm using /bin/mail under Linux, /usr/bin/Mail or /usr/bin/mailx under SunOS (actually a version of mailx swiped from a previous version of SunOS because I didn't like the behaviour of the mailx on this ISP as much as the one my previous ISP had installed).
I occasionally use Mutt to read a high-volume mailing list with long threads, to unpack or send MIME attachments, or to search quickly for an archived message, but I can't stand to use it for very long. The user-interface isn't sufficiently Glennish.
What I should do in some hypothetical parallel world where I have the time and the attention span simultaneously, is find the source code for /bin/mail and a couple of other versions of Berkeley mail that have features oddly missing from the Linux one, and hack it to Hell and back to make a modern MUA with the basic UI I like. (Basically add threading and MIME and choice of how to sort the message list from Mutt, and put back in proper recognition of the 'editheaders' variable from every other version of Berkely mail I've ever used except for the Linux one, along with 'noautombox' which about half of them honor, and maybe personalize the status flag to have more states than "New/Old-unread/Read" to suit how I tend to actually use my inbox these days. But still command-line driven.)
Ooh, you are hardcore, aren't you. I'm an (n)mh user; would you like to drink my Cool Aid? :) If you haven't looked into nmh, it's strictly command-line. However, no threading.
I'm working on that, but discovering that threading and email don't go so well together, because there are some amazingly stupid email clients out there generating really unhelpful headers. Do you know of any email threading logic which works particularly well, ideally living in some OS code I could study?
I glanced at mh a long time ago; I guess it's time to take a look at nmh. No promises though.
As for stupid MUAs and unhelpful headers, I'm pretty sure mine isn't in the helpful category (though I don't think it's in the "really doesn't play well with others" class either). Threading in email is a little hit-and-miss, yes, but Mutt manages to work some sort of magic so that while imperfect, it's still useful. If you want 100% reliable threading, it's just not going to happen.
I've never looked at Mutt's code, but I'm pretty sure the source is available.
I also know someone who pipes a mailing list into a local news spool; I should see whether I can find out what he does for threading.
(no subject)
I occasionally use Mutt to read a high-volume mailing list with long threads, to unpack or send MIME attachments, or to search quickly for an archived message, but I can't stand to use it for very long. The user-interface isn't sufficiently Glennish.
What I should do in some hypothetical parallel world where I have the time and the attention span simultaneously, is find the source code for /bin/mail and a couple of other versions of Berkeley mail that have features oddly missing from the Linux one, and hack it to Hell and back to make a modern MUA with the basic UI I like. (Basically add threading and MIME and choice of how to sort the message list from Mutt, and put back in proper recognition of the 'editheaders' variable from every other version of Berkely mail I've ever used except for the Linux one, along with 'noautombox' which about half of them honor, and maybe personalize the status flag to have more states than "New/Old-unread/Read" to suit how I tend to actually use my inbox these days. But still command-line driven.)
(no subject)
I'm working on that, but discovering that threading and email don't go so well together, because there are some amazingly stupid email clients out there generating really unhelpful headers. Do you know of any email threading logic which works particularly well, ideally living in some OS code I could study?
(no subject)
As for stupid MUAs and unhelpful headers, I'm pretty sure mine isn't in the helpful category (though I don't think it's in the "really doesn't play well with others" class either). Threading in email is a little hit-and-miss, yes, but Mutt manages to work some sort of magic so that while imperfect, it's still useful. If you want 100% reliable threading, it's just not going to happen.
I've never looked at Mutt's code, but I'm pretty sure the source is available.
I also know someone who pipes a mailing list into a local news spool; I should see whether I can find out what he does for threading.
(no subject)
(But I do own buttons that say, "Real programmers debug self-modifying code," and "Real programmers use oscilliscopes as debugging tools.")