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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers