[Please break lines on sane width. 80 is golden, 72 leaves room for quotations]
[2016-09-08 23:42] Link Satonaka <[email protected]> > What does the MH format do for us? If the intent of this project is > to modernize nmh, then what is MH doing to pull i ts weight- why is > it exempt from being “modernized”? 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 r cvstore. But, pushing content back to the mailserver quickly > becomes problematic. There are a number of things I coul d try, but > as far as I know, the best solution is a 3-way sync program written > explicitly to solve this problem- that is, it’s a hack written by > mmh/nmh users for mmh/nmh users. No offense to the developer > intended. Keep in mind, not everyone shares your assumption, that synchronization with mailserver (aka IMAP) is good and modern. MH format is beautiful by virtue of simplicity and friendliness to command line processing. Personally, I think it is extremely unsafe to keep your email on servers you do not control. Email is to be downloaded to my computer, at which point it no longer exists anywhere else. But if you insist, you have script. Am I correct, that you propose greatly complicate things only to make your particular style of email-management work out-of-box? > To my mind, this is insane. Why treat the symptom with an > *extraordinarily* complicated and highly specialized soluti on, > rather than simply addressing the *actual issue at hand*: the MH > format is too old. To interface with modern soft ware, we need to > update mmh to use maildir. Yes, because problem is actually highly specialized. > Another oddity to me as a new user is the separation of ‘pick’ and > ‘scan’. How much sense does it actually make that thes e are two > separate utilities? 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 inte nd to view the results of that search in > human readable form. Requiring an additional command to convert to > human rea dable form is not logical to me. What would you all think > of combing pick’s functionality into scan, giving scan a for mat > file that replicates pick’s output? Deprecate pick. pick $args | xargs rmm pick $args | xargs mhpath | xargs grep X-Foo: You miss spirit. > 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.
