What you're planning doing just isn't the MH way - it is instead the
"obvious" way, the way that seems like things ought to work, and then
without a lot of thought, jumping right into discussions of implementation
trivia, instead of analysing the design, and then doing things the right
way.
Well ... I understand why you're saying that, but let me explain my
position:
It's not clear to me that what you describe is the "MH way". Sure, MH
commands read the profile for default arguments; that makes sense to
me, and it's been that way forever. But things like "showproc" and "rmmproc"
have been understood to be shell commands that get called by MH programs
when necessary; having them be turned into tokens that take their arguments
from the profile seems a bit strange to me. I don't expect that to be
how things work at all, and it seems confusing to me. You may think
that it is obvious how things should work, but I think we're going to
have to agree to disagree on that. Nevertheless, people _expect_ that
things like "less -f" should work as a moreproc. What you describe ...
well, we can document it, but I think it will still be confusing. Also,
it's not clear to me how I could do something like
show -moreproc "less -R"
with what you describe (which I would argue SHOULD work).
Then there is the matter of consistency. As others have pointed out, we
already support what I would call the "obvious" syntax for mhshow handlers
(you give a shell command and any space-seperated options for each MIME
type you're interested in). So we'd either have to convert over the mhshow
entries to the "new" syntax (which sounds incredibly ugly) or live with
two completely different syntaxes for shell commands ... and that seems poor
to me. Really, we could think of this as normalizing how MH-invoked shell
commands work.
And I hate to bring it up, but what you refer to as "minutia", and
"which really don't matter much" ... well, that's a rather easy thing
to say when by your own admission you're not going to write any of the
code. If we had infinite time, sure, we could reimplement everything
the right way (although as we've seen, what people consider the "right"
way is sometimes completely opposite), but since we DON'T have infinite
time we have to live with stuff that is actually possible given the
free time of the contributors.
And I feel I must point out a significant implementation issue with your
suggestion. As it has been noted, right now we use the RFC-822 parser
to read in the profile. As a result, those tokens have to be valid
RFC-822 header names, but Unix commands aren't limited to that set.
Yes, a large number are, but certainly not all. I can envision ways the
syntax could be extended to make it work, but that just makes the code
(that you're not going to write!) more complicated, and, well ... there's
only so much free time.
And if I sound exasperated ... well, in my mind, we already HAD the UI
discussion, last May. There were no objections then. The only reason I
even sent anything to the list now was to get some feedback on a tricky
implementation detail. So saying that we didn't talk about the UI
first is inaccurate; we did that. Here's a quote from my email last
May:
To start, I have no idea how this interface should look like.
Suggestions here are welcome; code is even more welcome :-)
And this is what we ended up with. I'm not saying for every change to
nmh we have to do an IETF-style Last Call, but put yourself in my shoes.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers