Re: groff/-mandoc replacement

[Kristaps DÅonsons <kristaps%kth.se@localhost>]

> We have a few man pages with tables, and while I'm not too worried about
> them, adding very simple tbl support might be worthwhile.  See queue(3)
> for an example.

Antti, I'm running into the same issue elsewhere -- tbl, that is.  But 
what's the advantage, in terms of manuals already existing in base, of 
perpetuating tbl versus "Bl -column"?  Would it not be simpler to 
re-write these existing sections to use columns?  Apparently, older 
groffs had a two- or three-column limit.  This isn't the case with mdoc(3).

In fact, the mdoc(3) "-column" support, being tested in my local copy, 
has a superset of groff's functionality: it lets full macro "lines", 
like `Qq', exist in each column.

> > There was a very recent conversation about another reason to replace gproff,
> > which was to avoid C++ so the userland could be compiled with pcc.
> >
> > Just about the right time. Interesting!
>
> We also have a few non-mdoc documents in src.  Again, I am not too
> worried about these and we could move them to pkgsrc if we rip out groff.

Are new base manuals being written in non-mdoc?  Old ones can be pretty 
easily re-written.

> However, I assume we would have to install groff for just about any 3rd
> party package installing manual pages, since they are probably not going
> to be in clean mdoc but rather a mix of ``an'' and other roff commands.
> What would the command "man" do?  Would it become a frontend trying
> to decide which command to execute based on the path the manpage is
> found from?

I'm afraid I don't have an answer for this -- my intent was to deprecate 
groff for mdoc only.  I'm fond of mdoc because it annotates the meaning 
of macro arguments instead of merely their style (like the other macro 
packages).  The mdocml mdoc(3) "intermediate form", unlike groff's, 
encodes this information, which allows for all sorts of useful things:

 - quickly building an index of all functions in .3 manuals
 -                               ...executable names
 -                               ...etc.

This is already possible, if one wants to build such a frontend for mdoc(3).

As for coexisting mdoc/non-mdoc, I can't give an answer, as this seems 
to be administrative.  It's trivially easy to modify mdocterm(1) to punt 
to groff with a special error code immediately upon finding a non-mdoc 
macro.  Given the speed at which it operates (seem with time(1), 10x 
faster than groff), this could be done without noticeable loss.

Of course, this would assume that groff exists somewhere on the system. 
 As said, I don't have a quick answer for that.

Thanks,
Kristaps