Hoi Link, thanks for sharing your thoughts! I will gladly explain our world view in order that you learn to understand some of the status quo. But still, what you experience (and lucky us, even tell us) is what probably other new users will experience too, thus we should not decline it too quickly.
[2016-09-09 10:51] Dmitry Bogatov <[email protected]> > [2016-09-08 23:42] Link Satonaka <[email protected]> > > > > 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. And last, to answer your question: The MH storage format provides uns the greatest simplicity in sense of filesystem structure and interfaceability with traditional Unix tools. (At the cost of more complicated maintenance of the data.) > > If the intent of this project is > > to modernize nmh, then what is MH doing to pull its weight- why is > > it exempt from being “modernized”? Mmh is more modern than nmh (... at least way more modern than nmh was when mmh started; in the meanwhile the nmh guys have done a lot of modernizing as well (as far as I can tell)). Actually, however, mmh is ``meillo's mail handler''. It was just not so appropriate to title my Master's thesis this way. ;-) Mmh targets more the simplification and the exploitation of concepts than the modernizing ... and, yes, there are way more modern MUAs imaginable and even realized! (Mmh, to our disgrace, not even has a threaded view!) > > 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). > 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. > MH format is beautiful by virtue of simplicity and friendliness to > command line processing. Well said! :-) > > 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? ;-) It's the consequence of the probably most important lesson of Unix: Do one thing and do it well! Learn about the Unix philosophy, and you'll have good chances to understand it. > > As best I can tell, all this accomplishes is > > extra typing, usually with ungraceful use of backquotes (scan `pick > > -from whoever`). I imagine that the vast majority of times someone > > does a search, they intend to view the results of that search in > > human readable form. This surely is true (in the majority of cases). And the consequence for me was writing a script called ``pisc'' (for pick+scan) which I use almost always instead of pick(1): #!/bin/sh scan `pick "$@"` > > 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. > > Thanks for hearing me out. I know I’m new and I may not have as deep > > an understanding of the underlying mechanics at play, but sometimes > > it helps to have an outsider’s feedback to put things into > > perspective. > > It is... strange to request deprecation of something you do not > understand. Or is it pretty natural? ;-) 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
