Thank you for your replies! > [meillo] > > [Link] > > What does the MH format do for us? > > This is like asking: What does the hierarchical inode-based > filesystem do for Unix? -- The answer is: It it the basis and core > of everything. > > You're not the first one to suggest using maildir as the mmh > storage. The main reason why we don't do it is that it is not > possible to simply exchange the storage backend and still have the > same mmh. Similar: If you would replace the hierarchical > filesystem with something else, then it would not remain being Unix, > but something else. Well, it is not necessarily bad if it becomes > something else, but if you try to invent emailing anew, then it > would be much better to start completely from scratch. There are a > bunch of projects that go this way. Steering mmh on the same track > would not be successful. This is the reason why we don't > ``simply'' exchange the storage backend. > > What would be possible is making the MH storage virtual in sense > of FUSE and translating into maildir or IMAP. I think this approach > has some potential, but FUSE (AFAIK) has bad reliability and bad > portability. > > > [Dmitry] > > MH format is beautiful by virtue of simplicity and friendliness to > > command line processing. > > Well said! :-)
I still need further clarification on this point. I'm looking at two of the same plain text email right now: one in mh format, one in maildir format. There are but two differences: filename, and a few extra fields in maildir. Maybe there are more differences in terms of attachment storage, but the differences are very slight. Using FUSE would be unnecessary; why can you not patch each of mmh's tools to operate on maildir format? I fail to see how a different filename and a few extra lines within the text file create an impossible barrier. I'm not suggesting it's a small task, but I do not see how changing the backend will cause it to suddenly "not be mmh anymore". If I switch from ext4 to xfs, my OS doesn't suddenly stop being Linux. Unless there is some reason having MH is critically fundamental to the functionality of each tool... > [meillo] > > [Dmitry] > > Keep in mind, not everyone shares your assumption, that > > synchronization with mailserver (aka IMAP) is good and > > modern. > > Indeed. In my case, for instance, mail exists in the MH format > only! Incoming mail is passed from the MTA to the MDA, which > delivers it directly to the MH storage. I use mmh on the > mailserver directly, to where I ssh. I was afraid I'd bump into this. Let me assure you that my "assumption" IS how email works now. I understand your privacy concerns, but you cannot, *cannot* deny that synchronization with a mailserver is imperative. Of course, I don't expect mmh to be anything other than a MUA, but I *do* expect it to store email in an MRA compatible format. My request does not hurt your workflow in any way, it just makes mmh more flexible and modern. > [Dmitry] > [Please break lines on sane width. 80 is golden, 72 leaves room for > quotations] I will do so from now on, but this, THIS right here is a prime example of something ancient that should be modernized. No, not even just that: this is an old mistake that was never fixed. I am transmitting text to you- how that text is rendered is the job of software on your machine. This isn't necessarily within mmh's scope, the answer is probably to use vim or something as a pager which can intelligently format-wrap lines. Or a pager that can be configured to colorcode quotations, where the color ends with a newline (this is how imageboards handle this, see http://i.imgur.com/IxNHHPT.png ). In a perfect world, text is always transmitted without making assumptions about the recipient's machine. > [meillo] > > [Link] > > As it stands, the only way to > > actually sync mmh with a mailserver is to convert maildir or mbox to > > MH. Every single time you sync. With the help of this mailing list, > > I’ve written a script (which I’ve aptly named ‘inc’) to pull new > > content from my mailserver to a maildir, then move that into mmh > > using rcvstore. > > This is not the only way to do it. Philipp has a fairly usable > setup (AFAIK) that does not use rcvstore(1) or such stuff. His MH > storage is automatically synced with the IMAP server both ways > (AFAIK). Yes, Phillip is the one whose friend is working on a 3 way sync, and that seems to be his ideal solution. I find it unacceptable. I'll explain why further below > [meillo] > > [Link] > > Another oddity to me as a new user is the separation of ‘pick’ and > > ‘scan’. How much sense does it actually make that these are two > > separate utilities? > > How much sense does it make that ls(1) and grep(1)/find(1) are > separate utilities? ;-) No, this is different. 'ls' prints out useful, human readable information. 'pick' does not. > [meillo] > Learn about the Unix philosophy, and you'll have good chances to > understand it. > It's the consequence of the probably most important lesson of > Unix: Do one thing and do it well! It is the basis of the Unix Philosophy on which I request maildir format. There is a part of the philosophy you conveniently omitted: "Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input." Maildir is the format other relevant programs can read and expect to find. MH is a dead end and does not fit neatly into the Unix philosophy. Sure, we can string together a script of a half dozen other tools to achieve this functionality, (at the expense of efficiency), but... There is another philosophy I subscribe to: suckless. In fact, this is why I love mmh: you have created the most suckless mail client I know of, and I applaud you for that. http://suckless.org/philosophy But there is one misstep, one old bit of the original MH still hanging around and getting in the way. Writing scripts to move mail around, converting between formats- an unsightly, inefficient glue between two programs. This is not suckless. This is not good. What other option is there? A 3-way sync MRA? The complexity of that setup is mind numbing, no matter how you approach it. There is one graceful solution: an mmh which speaks maildir. > [meillo] > > [Link] > > Requiring an additional command to convert to > > human readable form is not logical to me. What would you all think > > of combing pick’s functionality into scan, giving scan a format > > file that replicates pick’s output? Deprecate pick. > > It would complicate the code and limit the possibilities. (This > is a question of Unix style.) But what I can think of is adding > a `-scan' switch to pick, which would automatically invoke scan > with the result. I think it would be worth considering that. If > the added complexity is small and the usability increases greatly > (you can add such a switch to the profile or we could even enable > it by default) ... > > In any way, I think that we should add our personal auxiliary > scripts to the repo, in a contrib directory. This idea is already > some time old, but the only outcome of it was Philipp writing his > ``config pr0n'' message to the list. Sure, adding a -scan argument to pick is fine. A contrib directory would be appreciated as well, but each config is only as good as its comments, at least for new users like myself. > [meillo] > Actually, however, mmh is ``meillo's mail handler''. I did know that, but I thought that was your way of being civil to the nmh crowd. > [meillo] > Anyway, there is a lot of -- and I am very serious about that -- > a lot of value in comments by an outsider! I believe that I had > only been able of having had this clear view on nmh, which lead to > the birth of mmh, by being new to it. Now already, I recognise that > I became more and more routine-blinded (in German: betriebsblind). > Hence, although several of your comments base on missing knowledge > about Unix and how things are done there, you also provide a fresh > newcomer's view that we lose more and more. > > > meillo Thank you for understanding. My criticisms and suggestions come from my love of mmh, and I freely admit that my input may be limited by my comprehension.
