bug-texinfo
[Top][All Lists]
Advanced

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

Texinfo command nesting and syntax checking: nested @ref


From: Gavin Smith
Subject: Texinfo command nesting and syntax checking: nested @ref
Date: Tue, 17 Jan 2023 21:26:54 +0000

Disclaimer: this message is not immediately practical.

When adding a new command (@useindex) to texi2any, I thought it could be
easier to define what is a valid nesting of Texinfo commands.

One thing I've noticed is that direct nesting of @ref commands is diagnosed,
but indirect nesting is not:

@ref{aaa@ref{bbb}}

@ref{ccc@b{@ref{ddd}}}

producing errors:

test.texi:5: warning: @ref should not appear in @ref
test.texi:5: @ref reference to nonexistent node `bbb'
test.texi:5: @ref reference to nonexistent node `aaa@ref{bbb}'
test.texi:7: @ref reference to nonexistent node `ddd'
test.texi:7: @ref reference to nonexistent node `ccc@b{@ref{ddd}}'

The "@ref should not appear in @ref" error only appears for the first
case.  Perhaps this misusage could be added to tp/TODO along with the
other erroneous constructs?

I may not be adding much by drawing attention to this, as it's unlikely
to cause a problem in practice.  However, the reason that I'm hopeful that
this and similar constructs could be diagnosed is that there are similar
constraints in HTML.  I was reading the HTML 4.01 DTD, at

https://www.w3.org/TR/html4/sgml/loosedtd.html

which contains for element <A>:

<!ELEMENT A - - (%inline;)* -(A)       -- anchor -->

The "(%inline)" part of this defines a list of inline elements, which
includes <A> itself, but the "-(A)" part is what is called an "exclusion":

> A few HTML elements use an additional SGML feature to exclude certain
> elements from content model. Excluded elements are preceded by a
> hyphen. Explicit exclusions override inclusions.
>
> In this example, the -(A) signifies that the element A cannot be
> included in another A element (i.e., anchors may not be nested).
https://www.w3.org/TR/WD-html40-970708/intro/sgmltut.html#h-2.3.3

I found it an interesting idea that the DTD defined the valid nestings
in a tabular, static data format, rather than as an algorithm.  In theory
a parser could be generated from the DTD using general SGML tools (although
I read this is not how web browsers did it historically).

Perhaps a similar approach could be used in the
tp/Texinfo/command_data.txt file, avoiding ad hoc and repetitous code
in the two parser modules to check for valid nesting?

I am just throwing this out there as a possibility, although it may not
be much use without specifics (i.e. how could valid nesting be specified
in command_data.txt).  I always found the code about nesting
commands hard to understand.





reply via email to

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