tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: groff/-mandoc replacement

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.


Home | Main Index | Thread Index | Old Index