>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
