As for fmttest -- yes, I looked at it, but the overhead of learning a
new debugging tool must be extremely low to make me change my
approach mid-stream. In this case, fmttest has the typical (of MH
programs) rich-but-very-dense man page format, and by the time I got
half way through partially understanding what it offered me, I decided
it didn't look much better than what I was already doing: I had three
windows open: one running "scan -form test.form", another editing
"test.form", and a third editing changes to a test message.
Well, I do appreciate the feedback ... and since I also wrote the man
page, clearly I need to do some improvement there (I was hoping specifically
the -trace option would be useful to would-be format script writers).
I am not sure if fmttest is to be used more in message mode or other modes;
I personally use it in raw mode a lot. But that's probably just me. That's
convenient (with -dump) to understand the actual instructions being generated.
(Anticipating your next "how would you improve the man page?" question:
Unless I misunderstand, I suspect fmttest is far more likely to be
used in message mode than in address, raw, or date modes, and
therefore it should be the first one discussed, rather than the
last. In addition, an example or two of how to use each of the modes
would be useful. Having working command lines to start with would
reduce the amount of yak-shaving necessary to get back to debugging
my actual problem.)
So sounds like some examples sure would have helped. Alright, noted! And
I'll look on reshuffling things around so message mode is first.
But really: it's not actually the debugging that's hard with mh-format.
It's the language itself :-)
I mean ... yes? There's a whole bunch of weird side effects and you're
stuck with only two variables. But replacing it would be a huge job.
--Ken