>This is the beauty of the MH design - which includes both the separate >commands, and the filestore (to link this in to the other thread...) that >things like this are truly easy to add.
There are some practical concerns about this, but what I'm thinking about is probably not what you'd expect. The suprising lesson I learned from writing replyfilter is that even when you add new code to solve a long-outstanding problem ... people simply don't know about it. I mean, the release announcement for 1.5 EXPLICITLY mentioned replyfilter ... and yet people replied TO THE RELEASE ANNOUNCEMENT asking, "Hey, is there anything that we can do about MIME replies?" (note there was like a few months of discussion about replyfilter). The second-most surprising thing I learned was that if it requires additional configuration, people won't configure it, for a variety of reasons (the most indicative response here is, from someone whom I asked if they were using replyfilter, was, "I don't know; am I?".). Part of this is probably interia, part is perhaps because their MH configuration was last changed in 1990 and they are loath to mess with it. This leads me to believe that if we want to have _effective_ calendar support, something sensible should happen in the default tools. You point out that you could write a shell script to deal with this, but I think that to make it a ROBUST shell script ... something that you'd actually want to ship, rather than a quick hack you just keep for yourself ... you'd need to do a lot of work. For one, we don't really have tools that are designed to output things like message structure to be consumed by other tools; those output formats have changed between releases, and I don't think any of us (at least in terms of active developers) have considered those output formats to be fixed. We've talked about solutions for that, but nothing's been implemented yet. So I think that leads me to think that the default tools should give you some indication that text/calendar support is available. Maybe that's as simple as creating a default text/calendar MIME handler that says at the bottom of the display, "Run mhical 45.2 accept to accept this calendar request", or something like that. Or maybe a repl should put a header in the draft that lets you easily accept or reject a calendar request. What I can tell you with a fair amount of certainty is that if we add something new without making the new tools aware of it, a large number of people won't be aware of it. This is important, but again, probably not for the obvious reasons. It's obvious that the user base of MH/nmh is shrinking, and the number one reason is lousy MIME support; that has a bunch of effects, and one of the most important is that with less users we have less DEVELOPERS, and we need developers if we want things like better MIME support. It would be nice if nmh continued being developed if David and I happen to die (It's not in my plans anytime soon, but who knows what will happen?). I get the feeling that if anyone does try nmh, dealing with MIME messages is so hard that people give up quickly and switch to a MUA that requires less out-of-the-box configuration. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
