groff
[Top][All Lists]
Advanced

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

Re: [Groff] man pages (tangential to Future Redux)


From: Tethys
Subject: Re: [Groff] man pages (tangential to Future Redux)
Date: Fri, 28 Feb 2014 21:15:06 +0000

"Eric S. Raymond" writes:

>Doug McIlroy <address@hidden>:
>> Perhaps Gnu's most egregious contribution to Unix
>> was to turn texinfo with its paleolithic interface
>> into the "complete" documentation with man pages as
>> stubs.
>
>You will be pleased to hear, then, that RMS and I have been
>discussing specifics of how and when to shoot this bad idea 
>through the head.

Great!

>Where we're probably going is that (a) info will die, to be replaced
>by HTML browsed from within Emacs, and (b) Texinfo will be replaced by
>a modern lightweight format that can render to both print and HTML;
>most likely asciidoc.

Oh :-( Not great. This sucks for those of us not using Emacs.

>Where I want us to be is that when users call man(1) the normal
>behavior is to render through the browser.

This is absolutely *not* where I want us to be. Currently, man(1)
is incredibly useful for me because it's quick. If I'm writing code,
I can suspend my editor, check the man page, and resume what I'm
doing. If I have to context switch to a browser window, that's a
significant problem. Further, it completely fails when I'm ssh'ed
in to a remote machine. You could argue for lynx or similar, but
that's an ugly hack that would deliver a significantly worse user
experience than the current reading of a manual in my pager of
choice.

You could perhaps argue that I should be using an editor that can
render HTML. But despite your protestations to the contrary in
TAOUP, Emacs is the antithesis of the Unix philosophy. I don't
*want* an editor that does that. I want an editor that edits
text.

I'm not intrinsically wedded to man(1), and am happy for superior
alternatives to take over. But while what you've described may work
for you, it's a major downgrade for my workflow and cannot in any
sense be considered superior. At the very least, you need to have
a fallback scenario where your asciidoc can render to a flat file
that's readable in the terminal in a pager. Yes, I'll be sacrificing
hyperlinks. Understand this: 99% of the time, I don't care (in the 1%
where I do, then I'm happy to spend a little extra time checking the
documentation in a browser or elsewhere). Further, this needs to be
a day 1 feature. If it's "well, there's no reason why this couldn't
be done", the likelihood is that it won't. Maybe you'll claim that
if dinosaurs like me want that feature, we should implement it. But
you're the one proposing to break something that's worked just fine
for 30+ years.

Tet



reply via email to

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