Larry Kollar <larry.kol...@me.com> wrote: |> Steffen Nurpmeso <stef...@sdaoden.eu> wrote: |> |>|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?) .. |>|> 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. ... .. |> 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. | |AT&T nroff had what they called “drivers,” a compiled data structure \ |that defined control codes for printer motions. In the early years of \ |my tech writing career, I wrote one to take advantage of the NEC Spinwriter’\ |s fractional motions; it supported stretchable spaces. GNU *roff doesn’t \ |really have that. A custom post-processor might fill the bill, but is \ |much more complex than a data structure. | |OTOH, a post-processor that hooked into terminfo could solve the problem \ |almost automatically, no? If the user’s $TERM supports color, and a manpage \ |requests color, then the user gets color. A register or string could \ |be defined to set a color for highlighting bold body text and/or headings.
I was indeed thinking about adding support for termcap/terminfo to the TTY output device, then. So it would know whether there are any #Co/#colors, how much of them, etc. Screen dimensions (also taking care for the standard $LINES and $COLUMNS). It could then of course also generate the sequences for bold etc. that the terminal expects instead of using the standard ISO 6429 ones. (The tty driver seems to use explicit SGR_ITALIC..SGR_NO_ITALIC, so that there is an exact feature on/off mapping, which should make this really easy to implement here. In my own things i have never done it like that but always presumed ISO 6429, where all attributes can be turned off with a single command.) And we surely could have a "simple" mapping mechanism that passes in some font attribute or colour and gets back something modified. This may become more complicated the more you look into it because of the versatile set of output devices. But this is C++ so this may even be object based fun in the end. --steffen
