[Top][All Lists]

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

Re: [help-texinfo] Formatting syntax rules

From: Laurence Finston
Subject: Re: [help-texinfo] Formatting syntax rules
Date: Tue, 7 Dec 2004 11:35:38 +0100 (MET)

On Mon, 6 Dec 2004, Karl Berry wrote:

>     would this cause any problems with respect to copyright?
> Nah.  Knuth first wrote all that stuff long before "free software" (let
> alone "open source") and the GPL came into existence.

Good.  I'll just go ahead then.

> As a result, many
> of his files are not legalistically pristine as the OSI would like.

What's the OSI?

> But
> Knuth being Knuth, I am not about to pester him to add copyright
> statements to these old files instead of working on volume 4.

I agree.  My rule number 1 is "never pester Knuth".

> Re @quotation, it's not important, but I still don't understand your
> objection to using it (if it helps).  It hasn't ever essentially changed
> since day 1, and I can't imagine it changing now.  Whatever.

I understand your point, and the fact that it works is a
strong argument in favor of using it.  However, grepping for
all address@hidden' or all address@hidden' is the sort of thing I
do.  I might decide to put all quotations in a different
font or add `\vskips' around all address@hidden'.  These
particular examples might not be sensible;  I just want to
explain why I want to use the markup to keep them separate.
I like using plain TeX anyway, so it's not much of a burden
for me to use address@hidden, @tex' environments and do separate
formatting for the other formats.  For somebody who doesn't
like using plain TeX, using address@hidden' might be a better
solution.  I won't go on about this, though, since I
understand why it would be tough to fix.

> Re adding support for syntax rules, I wasn't thinking of defining a new
> environment (I'm not sure if that's what you had in mind), but rather
> just one new markup command, say @bnfvar, which would output
> $\langle$argument$\rangle$.  Is that enough, or would you want more?

The other problem, in addition to my address@hidden' macro not
working in address@hidden', is the spacing before the alternatives,
i.e., following the `\vert'.  I've tried lining up the
`\verts' and the right-hand sides, but Knuth does it
differently.  I haven't decided what I like best.  If you,
as designer of the Texinfo format, want to make a decision
_ex cathedra_, I'll go along with it.

>     By the way, is there a particular reason why `texi2dvi' can generate
>     menus and links to the previous, next, etc., nodes,
>     while `makeinfo' needs to have them in the files?
> Um, I'm a bit confused.  texi2dvi doesn't generate any menus or links,
> unless you count the table of contents.

Sorry, I was confused.  What I really meant was that I
didn't need to include the `prev/next/up pointers' on
address@hidden' lines and the menus.  I thought that `makeinfo'
needed the former.

> However, given those, it is not
> necessary to write the prev/next/up pointers on the @node lines,
> makeinfo can deduce them (assuming a normally structured manual).  This
> is, in fact, the recommended way to write Texinfo sources.  It's
> described in the "makeinfo Pointer Creation" node of the Texinfo manual,
> among other places.
> There are Emacs commands for generating/updating menus (described in the
> chapter on the Emacs mode), although I rarely use them myself, I usually
> just write them in by hand.

I use them, but there are a couple of problems.   One is,
that the one that recursively updates all nodes and menus in
all input files writes some erroneous text in my top-level
file that I have to remove by hand.  The other is that
there are so many menus and they're so long that it clutters
up the files.  Therefore, I only do this when I'm working on
the final formatting.



reply via email to

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