[Top][All Lists]

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

Re: Manpage generation

From: Zack Weinberg
Subject: Re: Manpage generation
Date: Mon, 8 Apr 2002 09:30:20 -0700
User-agent: Mutt/1.3.28i

On Mon, Apr 08, 2002 at 11:39:50AM -0400, Karl Berry wrote:
> As Eli surmised, I was thinking more about the list of options, which
> can be spread over many, many nodes.  Does your script translate
> @itemize and the like?


> We're talking about implementing another output format, it would
> seem.  Sigh.

Well, yeah, except that the work is largely done already - it's just a
matter of (a) cleaning up the existing script, (b) deciding on the
official syntax for the markup, (c) making minor modifications to the
other Texinfo processors to handle the markup.

> What about the author, reporting bugs, see also, etc., sections?
> Those texts seem like they would not work at all in the context of a
> manual.  

Hence @ifman.  But keep in mind that you can select just a tiny
fragment of a Texinfo node for a manual section -- for instance, just
the sentence

        See http://gcc.gnu.org/bugs.html for bug reporting instructions.

out of the lengthy "How to Report Bugs" node of the GCC manual (which
largely duplicates the content of the webpage).

> Those "ancillary" things are the main reason that using the
> --help output seems better to me.  There is a much closer match
> between --help and man pages than Texinfo and man pages.

I disagree.  The content of --help is usually inadequate to create a
manpage.  It doesn't contain an overview description, anything to
create the SEE ALSO section out of, or even complete documentation of
the options.

> @mantitle [<section>] <programname>
> @manpart synopsis ... @endmanpart synopsis
> @manpart description ... @endmanpart description

Which is basically what I had, only with @man synopsis ... @end man
instead of your @manpart ... @endmanpart.


reply via email to

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