groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed: 3 disruptive changes for groff 1.23.0


From: Douglas McIlroy
Subject: Re: Proposed: 3 disruptive changes for groff 1.23.0
Date: Mon, 28 Jun 2021 18:05:53 -0400

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]