Re: [Groff] colorized man pages

[Steffen Nurpmeso]

Tadziu Hoffmann <address@hidden> wrote:
 |> Raw VT-100 escape sequences, in 2016.  Where will it all end?
 |
 |Steering wheels.  On cars.  In 2016.  Where will it all end?

I hope not for joysticks, or maybe only for cars driven by women.
Instead something more motorcyclish, where both hands can do
something.

 |Seriously:  what's wrong with escape codes?  I mean, if you're
  ..
 |still working with a text terminal, I'd expect escape codes to
 |be your daily bread and butter, not something to scoff at.
 |(Unless I'm missing the good-natured, approving irony here?)

Yeeeeaaaaah!  It seems control codes won't go away, Unicode adds
some more of them.

 ..
 |> It shouldn't be too much work to instrument a few important
 |> man and mdoc macros and add an environment variable, say,
 |> MANUAL_COLOURS, in equal spirit to LS_COLORS.  In the Linux
 |> world there is now a dircolors(1) command which can be used
 |> to control LS_COLORS.
 |
 |Coloring ls output adds semantic information from the mode
 |bits and the file type (normal files, device files, fifos,
 |links, etc.).  The "colored manpages" trick really has
 |nothing to do with man, it simply colors bold and underline
 |in the terminal.  To perform the equivalent of dircolors with
 |manpages will require actually rewriting the manual pages
 |and adding semantic information by hand (a *lot* of work).

Yes, i have read the referenced article.  That is a hack that
people use, but i was referring to something durable, regular.
For something semantically correct, yes, but – you know i had to
think about it – as a starter being able to define several
mappings wouldn't be that bad.  We have bold and underlined
output, why not warp that on request to something, _if_ the
terminal supports it.  I.e., /dev/tty i guess would have to be for
roff.  Also i think being able to map the plain roff colour names
would then be nice too, the blue that is used for URLs is really
screaming on this terminal, in the context of a manual.

  ..
 |> Black text on a white background has always worked well.
 |
 |On paper, using ambient light, yes.  On a self-luminous screen,
 |large areas of white are too bright and are hard on the eyes.

Situation has so much improved with the LED monitors, compared to
earlier times.  On a window system i still have a FC/FC/F9
background though.

  ..
 |> Adding colours to manual-pages is a solution to a problem
 |> that doesn't exist. It's purely aesthetic.
 |
 |Decidedly not.  It's in the same league as highlighting
 |words in bold or italic/underline.  Or are you saying that
 |this is superfluous as well?  Compare the following:
 |
 |  zcat /usr/share/man/man1/bash.1.gz | GROFF_NO_SGR=yes nroff -man | less
 |  zcat /usr/share/man/man1/bash.1.gz | GROFF_NO_SGR=yes nroff -man | \
 |  col -b | less
 |
 |I prefer the former.

Me too.

 |Another thing to keep in mind is that not all terminals can
 |display bold text (meaning a different typeface); some of them
 |substitute text with higher brightness.  It does strike me as
 |reasonable to give users some choice in the matter by allowing
 |them to switch to a different color instead (or in addition).

 ..
 |> Of course that isn't possible with [g]roff because [g]roff
 |> already throws away the information about macros in the
 |> preprocessor.
 |
 |Uh, no.  (What preprocessor, by the way?)  Apart from bold
 |and italic, the information simply isn't there.  And if it
 |were, you could of course transfer it to the output by using
 |a different implementation of the manpage macros.
 |This has nothing to do with the *roff syntax per se, but
 |rather with what has been captured by the manpage author.
 |
 |I think we have gone over this topic before on this list,
 |ad nauseam.  A long time ago, DEC had added semantic
 |information to their manual pages (all in [nt]roff format).
 |They called it "OSF Reference Semantic Markup Language"
 |and distinguished between ordinary text, emphasis, literals,
 |variables, alphabetic constants, numeric constants, system
 |(user) input, and system (computer) output, together with
 |markup descriptions of headings, lists, figures, etc.
 |Notwithstanding the effort, it hadn't really caught on.
 |My guess is because existing manual pages were "good enough".
 |Ultimately, they're intended to be read by humans, and if
 |humans understand them their purpose has been achieved.

I didn't know about this OSF.  mdoc is there and available
everywhere where groff (at least) is, and many programmers are
more or less aware of it.  And i agree ^.^.  But i dislike that
the very large GNU and Linux communities started trashing the
manuals they have with blue font attributes instead of doing
something real and adding some semantic to GNU and Linux manpages,
for URLS.  They had and they have control over all parts of the
pipeline.  A few weeks ago i have read that yet another approach
on documenting Linux kernel code is going to be evaluated, so
there are actually people who have interest and the will to go
a stony road.  We will see what the future brings, in my eyes
neither roff nor the manual system is at the end of any road, and
i would really like to see a better user experience.

--steffen