>>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
