Ingo Schwarze <schwa...@usta.de> 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
