groff
[Top][All Lists]
Advanced

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

Re: [Groff] Manpages, groff, and the browser.


From: Pierre-Jean
Subject: Re: [Groff] Manpages, groff, and the browser.
Date: Mon, 17 Mar 2014 14:14:40 +0100
User-agent: Heirloom mailx 12.5 7/5/10

Hello alls,

Kristaps Dzonsons <address@hidden> wrote:

> Even if groff(1) could do as above, and somehow carry over the original 
> macro language's "meaning", it'd be only as good as its input language. 
>   To wit, Eric proposed extending man(7) with semantics to address 
> exactly that.  And that would give us... another mdoc(7).
>
> While I agree that mdoc(7) is no semantic saint--sometimes it goes too 
> far, sometimes not far enough--it exists right now, has considerable 
> support and inertia, many eyes on macros and renderings, and has 
> demonstrable proof of capability.  mandocdb(8), via mandoc(3), dumps 
> manpages' semantic content into Berkeley or SQLite databases.  (Ingo, 
> who's captaining mandoc, can speak better on its status, as well as 
> -Thtml and friends.)
>
> And how exactly would groff(1) profit from a new macro language?  At the 
> very least, it'd require a whole new macro package to maintain.  And 
> groff(1) still wouldn't be able to understand semantics without "clean" 
> roff(7) and considerable work on internals.
>
> And how would the community as a whole benefit?  As a language, the new 
> man(7) wouldn't be much different from mdoc(7).  And then there's 
> balkanisation: we already have two language for manpages.  You're 
> proposing another?

I agree with all that.

Mdoc looks like a simple and obvious solution for the
semantic man problem. I believe that each project concerning
the semantic manual would study that possibility seriously.

Mdoc aims to be semantic, while man does not have that goal.
If the semantic goal of mdoc is not achieved, it's still
possible to improve it.

That's exactly what Ingo Schwarts proposed:

>  - improve the semantic usefulness of manpage markup by encouraging
>    and actively supporting the transition from man(7) to mdoc(7),
>    and carefully evolve and improve mdoc(7), while at the same
>    time continuing full support for the traditional man(7) macros,
>    completely unchanged, to support historic and autogenerated
>    documentation.

And Eric S. Raymond replied:

> Actively supporting is empty verbiage unless you have a mechanical
> translator from man(7) markup to semantically enriched mdoc(7). You
> don't, and I know exactly why you don't, because I wrote the pattern
> analyzer you would need and don't have.

Eric is wright: if doclifter could evolve to produce mdoc
document from man document, most of the semantic man problem
would be solved. Adapting doclifter in such a way could be a
great occasion to define in which point mdoc would have to
be improved.

Eric knows the solution and is the most competent person to
implement it. It would be a great gift to the community if
he would agree to do the job. It would also be a great
example of community conciliation.

Cheers,

Pierre-Jean.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]