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

[Joerg van den Hoff]

Eric S. Raymond wrote:
> Jon Snader <address@hidden>:
> > As a Vim user, I use the K command to pop up a man page in an
> > editor window when I need to check the exact usage or parameters.
> > I know that emacs users can do similar things with the M-x man
> > command.  Most serious developers use either emacs or Vim, so I'd
> > be willing to bet that they prefer to read most of their man
> > pages this way. 
>
> For me, it varies.  I sometimes use M-x man, and other times man(1) in
> an xterm.  I think I'd use HTML presentation more often than either if
> the things that should be hyperlinks really worked, and if
> ht://dig-style text search were available.
>
> > As a long-time reader of ESR, I know that he prefers to have a
> > *single* window on his desktop with an emacs window and
> > (presumably) a browser side by side.
>
> Actually, it's usually emacs to the right and a big xterm to the left,
> browser called up from the toolbar as needed and minmized afterwards.
>
> Right at the moment I have a third 80x25 xterm open in root, it's
> where I'm repeatedly doing "make install" to test groff man-page
> modifications.
>
> >                                     With this arrangement,
> > having the man page render in the browser exacts no extra cost
> > and has all the benefits that we've been discussing. 
>
> Your thinking is intelligent and cogent -- but your factual premise is
> wrong, leading you to an incorrect model of my assumptions.  On my
> usual desktop arrangement, rendering man pages in a browser *would* in
> fact have the cost of popping up a browser.  It is indicative that I
> don't have one up right now.
>
> >                   One could argue, I suppose, that this
> > just shows that ESR is correct and we should stick to a single
> > window, but there's a whole bunch of us who disagree.
>
> Heh.  For the record, "ESR" himself wouldn't make that argument. :-)
>
> >                      The important thing is that the behavior
> > be configurable for each user,
>
> Agreed.  I designed the changes to man(1) very carefully to achieve that.
>
> >                             and that we don't dismiss a desire
> > for the current behavior as indicative of arrested development.
>
> You skipped a step.  You have a good point about calling up manual
> pages within an editor, but not all character-cell displays are
> equivalent; it doesn't follow from this that man(1) through xterm has
> any value that lynx(1) through xterm wouldn't.  I'll be interested to
> see if you can make that argument, especially since Gunnar ducked it.

well at least I would argue that navigating with `less' through the man output
is superior to `lynx' for the same purpose
(even if you activate the "vi-mode" of navigation). `w3m' does look a bit more 
promising,
though, cause it seems to have been designed as a reasonable `more'/`less' substitute 
right from the start.
I silently followed the ongoing discussion on the list up to now. I'd just say 
that
I'm part of the "small stubborn minority" which is _quite_ happy with man(1) in 
an xterm.
no question, having the whole stuff as cross-linked HTML will be the preferred 
solution
for by-and-then users (and it will be sometimes/always for all/some experienced 
users).
my experience is that I usually don't miss cross-links in manpages: the usually few 
manpages of interest at any one time can be viewed in different xterms quite conveniently
(and for searching within a single manpage using `/some_pattern' is fine with 
me).
this is different from browsing through book size documentation like the complete `groff' 
manual. but before falling in the same trap of starting to argue about personal 
taste/preferences and a 'one_approach_fits_all' approach (how about starting a discussion, 
whether the use of MS Word should be prohibited globally?) I'd rather stop. sorry for 
interrupting...
> Until somebody meets that challenge, I'll stick with my diagnosis of 
> arrested development.  It's not one I make casually -- I've been thinking
> *hard* about Unix UI, from a position deep within Unix culture, for
> half a decade now.