groff
[Top][All Lists]
Advanced

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

Re: [Groff] Status of the portability work, and plans for the future


From: Eric S. Raymond
Subject: Re: [Groff] Status of the portability work, and plans for the future
Date: Mon, 8 Jan 2007 12:58:01 -0500
User-agent: Mutt/1.4.2.2i

Gunnar Ritter <address@hidden>:
> As I wrote, it depends on context.

And as I wrote, that's not a useful answer. Any portability rule that can't
be explained over a telephone and mechanically checked is going to become
irrelevant because authors simply won't apply it.  They have other things
to do than become expert in the sorts of fine troff distinctions that
would permit "depends on context" judgments.

I'd be willing to let you write the portability rules, provided their
complexity is not too high. and I suspect Werner would be also -- I truly
can't think of anyone better qualified and I doubt he can either.  And
despite arguing with you on specific issues, I like the way you think.

All that said, if you fall back on a vague "depends on context",
you'll have fluffed the job.  In that case I'll have to utter a
simple, stupid list of safe requests just to get something we can
actually use.

> Maybe. But still the tools should not complain if a troff
> expert has decided that something is safe.

And how are they going to do that?  Mental telepathy? :-)

> > 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.

That seems a reasonable compromise -- dead-simple rules with some
notice that experts can break them if they know what they're doing.
I'll add such language when I draft the portability guide.  Do prod me
if I let this slip.

> > 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.

And that is what, <1% of our potential userbase?  Sorry, but speaking
as one of those "experienced users" (an old Unix hand since 1982), I
think your vision is too narrow and geeky and parochial here.  If the
price of a decent hypertexted documentation system is as low as
causing minor inconvenience to a handful of crusty old Unix grognards
like us, it is long past time to pay it.

> > 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."

Ah, I see we were talking past each other.  I'd be quite willing
to write it that way.  You win, problem solved.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>




reply via email to

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