> > 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... > > When I see in my `scan' output message number 4, I know exactly it's > filepath. If I see in my `mutt|iceowl|...` a message number 4, it is > pain to get filepath. And it is pain to type it even with shell > completion. > > I do not want unreadable filenames just because. This is what mhpath is for.
> > 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. > > No. It is how your email work. As I already said, mine does not. I do > deny that synchronization with a mailserver is imperative. As I have explained twice now, I am not telling you to change your workflow. My request does not require that you change your workflow. At this point, you are merely telling me that I, and the vast majority of email users, are not welcome to use mmh. > > > [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. > > Text formatting is power. And sometime I want to > exercise > this power > for expressiveness. To protect it, it should be delivered as-is. If your setup cannot render text properly, that is your problem. A problem the rest of the world solved decades ago. > And, by the way, stop yelling "modernizing". Modern != good. Web sites, > that do not work without 0.5Mb of proprietary JS are modern, but it's a > shame. Not everything modern is good, but your ancient habits are not untouchable, either. Modern software is a mix of ideas, both good and bad. My goal here is to bring some of the good ideas and advancements to mmh. > > > 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) ... > > sarcasm: > Then -rmm, -mhpath too, please. > If you do not intend to be respectful in this discussion, I have no use for your input. -Link
