[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.
- Texinfo command nesting and syntax checking: nested @ref,
Gavin Smith <=
- Re: Texinfo command nesting and syntax checking: nested @ref, Patrice Dumas, 2023/01/18
- Re: Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/18
- Re: Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/18
- Re: Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/18
- Re: Texinfo command nesting and syntax checking: nested @ref, Patrice Dumas, 2023/01/18
- Re: Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/21
- Re: Texinfo command nesting and syntax checking: nested @ref, Patrice Dumas, 2023/01/21
- Re: Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/22
- Re: Texinfo command nesting and syntax checking: nested @ref, Patrice Dumas, 2023/01/24