"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> What requests would you say are "visually safe" in the way you are defining
> that are not on the portable list? (It is presently .de .ds .fi .ft .ie .if
> .ig .nf .nr .rm .rn .so .sp). You make a case for .hy/.nh/.ad; what others
> would you add?
As I wrote, it depends on context. I can understand that a
.br out of context might be difficult to interpret. On the
other hand, both .br and .ns
.TP
of=
output file name; standard output is default
.br
.ns
.TP
.RI ibs= n
input block size
.I n
bytes (default 512)
.br
.ns
.TP
. . .
(Unix 7th edition dd(1)) should be safe here because the .TP
contains every information you need.
> I see what you are driving at, but there is a practical problem with
> this style of rule; it's too complicated. It probably can't be
> mechanically checked, and it's going to make people who aren't troff
> experts crazy trying to apply it, and they'll get it wrong, and before
> too long they will give up trying.
Maybe. But still the tools should not complain if a troff
expert has decided that something is safe. So while it
would certainly be desirable to have a "lint" mode which,
when explicitly enabled, tells about every possible
portability problem, such warnings would be a nuisance
in the normal mode of groff -man.
> My opinion is that a certain amount of loss of fine control over
> vusual output is an acceptable tradeoff for getting a set of rules
> that non-experts can apply and will be willing to apply
Okay, for the set of rules, you may be right, although the
guide should at least mention that there is some level of
formatting beyond that if somebody is experienced and is,
if in doubt, willing to test what he has written.
> especially
> since I think the future belongs to browsers, where you can't get
> precise visual control anyway without heroic measures that are a
> bad idea for other reasons.
This is too simplistic. While it is clearly desirable to
have manual pages that can be displayed in browsers, it
is a safe bet that many experienced users will continue
to view them on a terminal.
> > > But here I think you are setting too high a hurdle. I will be
> > > very surprised if AIX or HP-UX are relevant to *anything* other
> > > than a handful of aging legacy systems in two years' time.
> >
> > We will see; this is certainly possible. But as I said,
> > we are not the ones who make the decision here. We can
> > only observe what happens and write our recommendations
> > accordingly.
>
> What sort of trigger point would you fin acceptble? When proprietary-Unix
> market share falls below 10%? 5%? 1%?
I can only repeat: It is not our decision. Somebody might
find it important to support AIX even if its market share
(whatever this may be, in fact) is .1%. A portability guide
has to describe the facts: ".EX and .EE are currently
predefined on systems A, B, and C; system X lacks support
for them. If you intend your software to be portable for
X, you should include the definitions for .EX and .EE at
the top of your manual page."
Gunnar
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
