> Not using such a file [a tmac striipper] makes the software less effective; > thus such a move ["skip the stripper"] is simply a sabotage.
I am not at all convinced of the first claim above. Please provide some hard evidence for it. (A simple assertion that stripping dramatically shortens some tmac files is not evidence for any effect on software effectiveness, i.e. correct performance on all inputs, and timely performance on realistic inputs.) > Is there also a consensus, that the maintainer, that introduced this > mechanism of removing meaningless (time, energy, processing cycles > wasting) bytes, made a mistake, an error? Barring a surprise answer above, I vote a vigorous yes. Stripping, I believe, gratuitously impairs readability. If an infelicitous tmac file deploys so many comments and indenting spaces within time-significant macros as to perceptibly affect performance, the right solution is to correct, not embalm, these rare stylistic flaws . Furthermore, stripping is almost certainly impossible to do right. How, for example, do you know that a line in a macro that begins .\" is a comment? You have no idea whether . will be the control character when the macro is expanded. Yes, it's a cooked-up example that can be overcome by an equally cooked-up -u flag in the source repository. Occom would not approve of this multiplication of entities. Doug
