[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The varieties of mdoc experience (was: Running the grohtml pipeline as a
From: |
G. Branden Robinson |
Subject: |
The varieties of mdoc experience (was: Running the grohtml pipeline as a pipeline) |
Date: |
Sat, 23 Mar 2024 20:41:46 -0500 |
At 2024-03-23T00:08:27+0100, Alejandro Colomar wrote:
> > Maybe I should do with grohtml what наб accused me of doing with
> > mdoc:
>
> Any links to that? Sounds like a funny discussion. :D
https://savannah.gnu.org/bugs/?65101
I admit that sometimes I enjoy disputation. This was not one of those
times. What I have seen of наб's work product is consistently diligent
and scholarly. I feel badly when I antagonize people who do good work,
even inadvertently.
наб did help me discover a mistake of mine; when I said I was correcting
a bug noted in groff_mdoc(7) (and in mdoc.samples before it) with one
aspect of my changes to `Nm`'s rendering, I was wrong. What had
happened was that (I think) Werner Lemberg or Ruslan Ermilov fixed it
when they rewrote groff mdoc(7) in proper groff instead of the AT&T
dialect, but no one remembered to update that part of the man page. So
something I thought was documentary of a defect with the status quo was
actually outdated material.
Also, наб's strongly aggrieved message motivated me to dig up and make
handy for myself a copy of 4.4BSD's mdoc implementation, so that I could
easily A/B compare it with groff. And that's a right thing to be doing.
I had been using just mandoc(1), but apparently to наб, Ingo Schwarze
and I are like Indiana Jones and René Belloq: we have both fallen from
the pure mdoc faith. :)
It may be also cold comfort, since I still have no intention of making
groff mdoc(7) produce slavishly identical output to 4.4BSD, but I much
prefer to "deviate", in Ralph Corderoy's term, in an _informed_ way.
(And I note, _slavish_ identity with 4.4BSD output could require us to
re-introduce bugs.)
> I was actually a bit surprised that Paul Eggert mentioned grohtml(1)
> as an improvement over man2html(1). While man2html(1) is ancient and
> quite bad... grohtml(1) output is on par with that. Let's improve
> that! :)
Sure. Maybe we'll find out that there's someone out there who loves
grohtml 1.23's output as much as наб loves groff 1.22.4 mdoc's, and I
can get my ass chewed out again. 😅
Regards,
Branden
signature.asc
Description: PGP signature
- Running the grohtml pipeline as a pipeline, Alejandro Colomar, 2024/03/18
- Re: Running the grohtml pipeline as a pipeline, G. Branden Robinson, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, Alejandro Colomar, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, G. Branden Robinson, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, Alejandro Colomar, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, G. Branden Robinson, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, Alejandro Colomar, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, G. Branden Robinson, 2024/03/22
- Re: Running the grohtml pipeline as a pipeline, Alejandro Colomar, 2024/03/22
- The varieties of mdoc experience (was: Running the grohtml pipeline as a pipeline),
G. Branden Robinson <=