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

[Eric S. Raymond]

Gunnar Ritter <address@hidden>:
> Yes, and authors would also get nasty bug reports from
> people who compile their manual pages with the switch
> turned off because it is the default. This would be as
> bad as gcc shipping with -Wall enabled by default.

Only authors who didn't strict-validate their pages would get those
reports -- which is exactly the effect we want, I think.

> I know for sure that many people will prefer man output
> on the console since they do not care about (a) to (d) but
> about having quick access to informative texts.

So tell me.  Exactly how much slower would it be if, when you
typed "man foo", a browser popped up and displayed foo(n)
in HTML?  

Gunnar, Linux man(1) can do this *now*.  I added the code myself over a
year ago.  All that's needed is for HTML pages to be in the right
places under /usr/man and it's game over.  Of course, if you were 
insistent on a crappy presentation, you could always set BROWSER=lynx 
and get behavior almost as primitive as man(1).  Sorry about the
working hyperlinks.

>                                                This is
> simply because these people can already use hypertext
> documentation (e.g. using the KDE system we examined) but
> do not do so.

I respectfully submit that I probably understand this phenomenon
better than you do.  I've been thinking about it, and conducting
experiments to test my theories, for about five years now.

Four years ago, I wrote the most carefully-developed argument for the
superiority of Unix-style CLIs over GUIs since Gentner & Nielsen's
"Anti-Mac" paper in the mid-1990s.  It's in "The Art of Unix
Programming" (2003), especially chapter 11.  Read it at:

         http://www.catb.org/esr/writings/taoup/html/interfacechapter.html

As mercilessly as I am pounding you about one half of your position
(the bizarre, retro-fetishistic attachment to display via terminal
emulators), you're perfectly right about the other half; for
experienced Unix users, typing 'man foo' is a lower-overhead alternative
than clicking through a web hierarchy.  

But the preference for man(1) is not, in fact, a preference for
reading nroffed output on an xterm -- it's a preference for a
*retrieval protocol*, a set of reflexes about how to *find* stuff.
The display channel is nearly irrelevant to that preference.

I think I can prove the above statement with a simple thought experiment. 
Suppose your man(1) were replaced tomorrow with a trivial wrapper
that formats the manual page to Postscript and pops up an instance
of gv on the result.  After the first thirty seconds, would you care?

If you're like most people who think they "prefer man(1)", the answer is
"no".

You have these two issues (retrieval protocol vs, display channel)
confused, so when I talk about moving to hypertext you flinch and
assume that I want to kill off the good things about man(1), which are
(a) the retrieval style, and (b) fast, lightweight operation.

But that's not a problem in my head, it's a problem in yours.  *I* have
not confused the man retrieval style with its display channel; That's
why I fixed man to be able to use a browser *without changing its
invocation protocol*.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>