Re: [help-texinfo] Formatting parser symbols and rules

[lfinsto1]

> Sorry, I can't reply to everything in detail now (and I'll be offline
> after tomorrow until next Wednesday), but here are a few notes.

Don't worry.  Like I said, this is more for a "TODO" file, (possibly), and
not for instant solution, or any solution at all, necessarily.  I'm
reasonably happy with my kludges.  If my own situation ever allows it, I'd
be interested in working on Texinfo myself.

>
>     1.  It would be nice to have a set of address@hidden' commands for parser
>
> I would prefer not to add any more @def commands for specialized
> application.  They're a big pain.
>

Okay, point taken.

>     tokens (address@hidden') and one for non-teminals (address@hidden') and 
> add the
>     entries by hand, so the entries in the Variable Index are redundant.
>
> Maybe redirect the vr index to pn, then, and omit the explicit pn entries.

That wouldn't work, because there are many other variables that need to go
in the variable index.   I'd like to keep the parser symbols separate to
reduce clutter.

> I highly recommend redirecting all indexes into one in the end, anyway.
>

Oh, well we obviously disagree on this point.

>     This works fine, except that it doesn't work for the first item in the
>
> Well, that's a bug, but it seems like an awful lot of trouble.  How
> about simply using @var?  That's what it's intended for.  Maybe we
> should invent a formatting option that says whether or not @var should
> use angle brackets, or a second command (say, @metavar) that does have
> angle brackets.  Or maybe just forget the angle brackets, even though I
> know they are highly traditional in parser descriptions.

address@hidden' puts the text in a slanted font in the TeX output, except for 
`[]'
in address@hidden', as I've determined.  I suppose it wasn't meant to be
used this way, but I don't think this is a good enough reason to change it
to `char** argv'.  I'd have to look up whether there's a semantic
difference.  I prefer this style of declaration to `char **argv', even
though the latter is probably more correct.  Declarations like `char c[]'
are awkward to format, anyway, since address@hidden @var{c[]}' would seem to
make the brackets part of the variable rather than the type.  I don't
suppose that this problem can be solved.

If I change the underlines to spaces, than something is needed to hold the
names of the non-terminals together.  I could just format the parser rules
in Bison's syntax, e.g., `statement_list: statement_list statement', but I
prefer Knuth's formatting.  Another problem is the direction of the
arrows.  When using Bison's debugging facility, the arrows point the other
way, which is potentially confusing.

Please don't make changes to address@hidden' on my account.  An address@hidden' 
command
that doesn't work on the macro level would be nice, though.  When I run
`texi2dvi', the file `scantest.tmp' is included what appears to be
hundreds of times.  After the run, it contains this:

@iftex
@tex
$\longrightarrow$
@end tex
@end iftex
@ifhtml
@html
→
@end html
@end ifhtml
@ifinfo
-->
@end address@hidden

I therefore assume it is used to handle macros.  It slows things down, and
creates a lot of ugly terminal output, but isn't otherwise a problem.
>
>     it's not possible to use `@ ' in an index entry.
>
> What happens?  I don't know of any explicit restriction.

It works with `texi2dvi', but `makeinfo' fails:

c:\Scantest\DOC\TEXINFO//parser.texi:235: Unknown command `'.
c:\Scantest\DOC\TEXINFO//parser.texi:235: Unknown command `'.

In addition, address@hidden' causes `makeinfo' without `--html' to issue
the following (annoying) warnings:

c:\Scantest\DOC\TEXINFO//glblfncs.texi:41: warning: unlikely character [
in @var.
c:\Scantest\DOC\TEXINFO//glblfncs.texi:41: warning: unlikely character ]
in @var

For some reason, they aren't issued when the `--html' option is used.

>
>     Some of the address@hidden' lines are also very long, and I think 
> `makeinfo'
>     at least will fail if they're broken.
>
> @node commands definitely have to be on one line.  But do you really
> have individual node names that are longer than 70 chars or so?  Yikes.

Yes, with the `Top', `Up', and `Next' references inserted by Emacs'
`texinfo-multiple-files-update', e.g.,

address@hidden Arithmetical Operators Parser, Boolean Operators Parser, \
       Operators Parser, Operators Parser'

I call `texinfo-multiple-files-update' function with a positive numerical
argument, and I always have to delete an extra address@hidden' in the main
file (`scantest.texi') by hand.

Thanks,

Laurence