groff
[Top][All Lists]
Advanced

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

Re: Plan 9 man added a new macro for man page references


From: G. Branden Robinson
Subject: Re: Plan 9 man added a new macro for man page references
Date: Wed, 11 Aug 2021 00:58:31 +1000
User-agent: NeoMutt/20180716

Hi, Ingo!

At 2021-08-04T14:46:18+0200, Ingo Schwarze wrote:
> G. Branden Robinson wrote on Wed, Aug 04, 2021 at 02:06:09PM +1000:
> 
> > I owe Doug McIlroy an apology for, some months ago on this list,
> > significantly understating his diligence as editor of Volume 1 of
> > the Version 7 Unix manual (1979).  A meticulously numerical
> > accounting of just one aspect of that effort follows in this
> > (lengthy) email.
> 
> Interesting.  So v7 actually used I(R) outside and R(R) inside SEE
> ALSO, almost consistently.  Which means you do have tradition on
> your side.

It's a strange sort of vindication for an iconoclast by temperament, but
I'll take it.

> Ah yes, the usual problem that the roff pipeline discards all the
> semantic structure right at the beginning and that the output devices
> no longer have access to information contained in the source document,
> in this case "this was a manual page cross reference".
> 
> My point is -O man= / \*(MB is a job for the output device.  It is
> totally different for HTML or terminal or PDF output.  The HTML
> output device wants to build URIs and hence likely needs a base URI,
> but that's completely useless for the other devices.  So logically,
> making it an option to the output device/postprocessor (like grohtml)
> would seem adequate.  But that doesn't work with roff pipelines already
> having discarded all the required information...  :-(
> 
> So maybe some layering violating contortions invading the macro
> package files like the ones you mentioned are needed.  Not sure,
> it still feels disgusting to me, but if no better idea can be found...

I think the problem is analogous to that which has led to ever-more
expressive debugging info formats for code that compiles to native
machine language.  One of the reasons it took so long to get really
helpful error messages from C compilers was that so much information
about the source text got discarded by the time the actual translation
process was taking place.  What gets us the little under-squiggles and
carets and spelling-correction suggestions now are...layering-violating
contortions.

Questions of traceability and auditability, among more prosaic concerns
like figuring out what the heck the compiler is actually complaining
about, to me, reveal the Unix filter model to be less a cost-free stroke
of unalloyed genius and more of an engineering trade-off.  It made
things possible on 16-bit machines with 16- (or, effectively, 17-) bit
address spaces that would not have otherwise been, and that's a win for
economics.

And indeed Unix was a win, especially for its time--but people who loved
their top-to-bottom integrated Smalltalk or LISP environments (to the
extent that I can imagine their daily experience), weren't crazy.  They
saw valuable things there.  As I see it, Rob Pike and others tried to
capture some of that consistency with Plan 9 (and Rio, and a major
rethink of terminal management).  But people hate learning new
things--they are aggressive adherents to the sunk cost fallacy.  AT&T's
attitude to licensing was probably sufficient to kill Plan 9 as a
popular solution all by itself, but even if it hadn't, I think it still
would have failed, because "worse is better".  There were a lot of
people out there who thought SunOS 4 was the peak of OS design.

(Similarly, people believe that Mach proved once and for all that
microkernels were inefficient and would forever be so.  Or they're
simply hooting fanboys of Linus Torvalds's [erstwhile?] approach to
technical critique and hopped on his bandwagon without understanding
what the argument was.  You can put Jochen Liedtke's empirical
measurements[1] in front of people all day long and they won't change
their minds.  [Spoiler alert: Mach wasn't a very "micro" microkernel.
Its working set was too big for the machines it was deployed on.  Mach
was, at that time and in that form, probably doomed anyway.  To slim
down it would have had to look less like Unix, and even it that meant
pushing some fundamental Unix concepts into userspace it still would
have been too discomfiting to ever win among Unix fanatics.)

(Did I digress some?)  At any rate, I don't think an MB string is too
offensive, because almost no one will need to know about it.  man(1)
implementors, and us, are about it.  At present man-db man(1) and
Brouwer/Lucifredi man(1) [does anyone still ship that?] don't, I think,
permit the user to specify *roff string or register definitions at the
command line, so assuming MB gets out the door before Colin Watson acts
on my request to add such a feature (to tune page rendering options),
users won't even be able to meddle with it without editing man.local.

Regards,
Branden

[1] https://www.cs.fsu.edu/~awang/courses/cop5611_s2004/microkernel.pdf

Attachment: signature.asc
Description: PGP signature


reply via email to

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