groff
[Top][All Lists]
Advanced

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

[Groff] The case against the case against .EX/.EE & .DS/.DE


From: Eric S. Raymond
Subject: [Groff] The case against the case against .EX/.EE & .DS/.DE
Date: Wed, 27 Dec 2006 13:58:30 -0500
User-agent: Mutt/1.4.2.2i

Gunnar Ritter <address@hidden>:
> If you are using only few additional software as usual on a
> production machine, there is no actual need to install groff
> since manual pages are mostly portable to AT&T-derived nroff
> -man in practice. We should not deliberately break that.

I feel at this point I should remind you that I'm an old-time Unix guy
myself going back to 1982 -- so that when I say "this wouldn't bother
me very much" you might be less inclined to take my head off :-).

Yes, normally I would be a stickler for backwards-compatibility to
legacy Unixes.  However, I feel that in the particular case of .EX/.EE
and .DS/.DE there are several factors which, taken together, would 
make the slight degree of breakage involved an acceptable trade-off.

1. If my corpus is reasonably complete with respect to the open-source 
packages that might be back-ported to legacy Unix (and I think it is), 
only a tiny fraction of legacy pages would be at issue -- fewer 
than 0.9%, in fact.

2. The bad result of not having these defined is that multiline
examples and displays will lose their line breaks.  Single-line
examples probably won't be affected.  Single-line displays are the
dominant case; I'd have to instrument to be certain, but I'm pretty
sure the ratio is something like 5:1, for an actual page-read impact
of less than 0.15%.

3. These macros are already present in at least some legacy Unixes.
Notably, .EX/.EE is in Ultrix/OSF-1.  I'm not sure where .DS/.DE
came from, but considering the relatively large number of uses without
local definition I'm sure it must be historical somewhere.  So the
actual impact would be on fewer than 0.15% of page reads even if we
ignored groff-using systems completely.

In order for this change to bite once we get an updated man macro 
package deployed, somebody would have to fulfil all of these conditions:

1) Not using groff
2) Not using one of the legacy Unixes where these are already defined.
3) Looking at a multiline display or example.

I think that this case falls well below my 0.5% threshold for
statistical noise, and that we can slightly break it without qualms.
And there is objective evidence from the behavior of users; if this
were a big deal, the 100-odd undefined uses in my corpus would have
been reported as bugs and fixed before now.

I also think it's not completely irrelevant that the legacy Unixes
are hemhoraging users and installations at a rapid clip.  In the future,
groff man will be behind a larger percentage of man(1) instances rather
than a smaller one.

I wish to note that there is no other man extension that I
would push in this way.  The number of man pages that could be
cleansed of low-level troff markup by means *other* than .EX./.EE and
.DS/.DE is, in my informed judgment based on inspection of the corpus,
vanishingly tiny.

Finally, I think we are now at a near-optimal time to do this.  We
can deploy to an extremely large percentage of Linux systems if
we get 1.20 out in time for FC7 and Debian etch, both of which
will probably ship 1Q 2007. 
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>




reply via email to

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