Tadziu Hoffmann <hoffm...@usm.uni-muenchen.de> 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
