I don't think that's a good idea.
If it's not too much trouble for you, I'd like to understand why this is so.
David explained his reasons (which I share), but I'll expand on mine.
I have sort of a love-hate relationship with mh-format(5). The love part is
that it's terse and the implementation is (mostly) compact and well-written.
The hate part is the language is woefully underspecified, has only two
variables, and has a bunch of side-effects in the implementation that make
it difficult to write a complicated mh-format program unless you study
the implementation.
So, part of me wants to make mh-format better; part of me wants to kill it
and replace it with a better embedded language. Lyndon is working on adding
Lua support; that's a probable replacement. But I've certainly guilty of
adding features to mh-format(5); I've rototilled the memory management,
added a bunch of functions, and I've added fmttest(1).
So, where do I draw the line at adding features to mh-format? Good
question; I guess I make that call on a per-feature basis. So that's
why I don't want to add everything under the sun to mh-format.
As for THIS specific feature ... well, mh-format is used in a lot of
places. For example, it can be used on message reception (by rcvtty),
and it's used in inc, repl, and now forw and comp. We'd have to think
carefully about the security implications of allowing callouts to
programs. Also, since there aren't too many true string handling
functions in mh-format the normal ways of santizing input or output
aren't available. It just feels like the wrong approach; I know that's
not a great answer, but I don't have a better one.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers