Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

Ingo Schwarze <address@hidden> wrote:
 |G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:14:58AM -0400:
 ...
 |> If that means a new macro, I'm fine with that.
 ...
 |For man(7), introducing new macros would be worse.  There, it would
 |utterly break portability because other implementations do exist,

Now i really oppose that.  That is utterly shit, Ingo.  You can do
whatever you want, except for "security sandbox" restrictions
(iirc some commands don't work).  You could use the painting
commands if the output works fine on the tty even.  You could
dynamically generate parts of the manual page.  Most people don't,
but they could be almost completely free if they want to, and
i for one consider this as something important.

Of course such things won't work in mandoc then, but 99.9 percent
of all manuals will do just fine, and much, much faster than roff
will ever be able to serve.  While you complain about the somewhat
broken grohtml, the HTML output of mandoc used repeated
per-paragraph style directives and a CSS file, which caused
enormous bloat, last time i tried.

  ...
 |I'm a strong believer in incremental software development.  But
 |there are exceptional cases where incremental improvements are not
 |viable, in particular when the basic paradigm employed is busted
 |and the language is a dense tangle of historically cemented layering
 |violations.  The man(7) language is one of these cases.  Fortunately,
 |it has been obsolete for 25 years now, and mdoc(7) is mature and

Oh, come on Ingo.  man is obsolete for 25 years?  In the BSD
world, of which i feel part of for almost fifteen years myself,
but that is not the motor of the software world, by far.  Of
course you can build a car with only stolen parts.  Still, those
have to come from somewhere.

Btw., if you want really clean man(7) you should point people to
the really good guys, e.g., the plan9port manuals are a phantastic
example of minimalistic and pure pages.

 |> My recommendation is to take the momentum an-ext has, however small, and
 |> press it:
 |> 
 |> a.  Add more macros to fit semantic needs and the hiding of lower-level
 |>     requests and escapes.
 |> b.  Hand-hold users to the nth degree with examples and recommended best
 |>     practices.
 |> c.  Show people a mapping from groff's "extended" man macro package to
 |>     mdoc, so that the route for switching over is clearly signposted.
 |
 |It seems to me that b) is fine, a) is very problematic because it
 |severely harms portability, and c) may or may not help to convince
 |people.  I'm not sure the intermediate step of reinventing man(7)
 |as a semantic language will make the transition easier.  Why should
 |people have to learn a new man(7) language in between, in addition
 |to the old man(7) and in addition to mdoc(7)?

Even though still without voice, a) is in no way problematic if
the original roff command set is used and no wild and funny
programming sessions lead to mandoc incompatibilities.  b) is
fantastic, c) i don't really believe in, mdoc has quite some
similarities to brainfuck, things like

  .Op : Ns Fl c Ar cc-addr Ns \&:
or
  .Fl S Ar var Ns Op Ns = Ns Ar value Ns

are nice for teaching, but no one can really promote something
like this, can he.

And sometimes things have to be adjusted a bit so that things can
overall stay the same.  The roff system is a fantastic
achievement, and if at all possible i will use it until the day
i die.  I am looking forward for my thing.

--steffen