[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
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
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
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.
Main Index |
Thread Index |