Re: Texinfo command nesting and syntax checking: nested @ref

[Patrice Dumas]

On Tue, Jan 17, 2023 at 09:26:54PM +0000, Gavin Smith wrote:
> Disclaimer: this message is not immediately practical.
> 
> One thing I've noticed is that direct nesting of @ref commands is diagnosed,
> but indirect nesting is not:

Indeed, this is a long-standing issue in texi2any, and should be,
nowadays relatvely easy to implement because there are commands stacks.
The reason why I did not start working on it is that I fear that it will
have an impact on the performance, as it would mean that for each
command, the stack of commands would be checked.  I am not completely
convinced that the performance penalty is worth it.

> 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":

It is actually fairly rare, as far as I can tell, besides the one you
mentioned, and in practice browsers render correctly such cases.

> 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?

The current approach of classes of containing and contained commands
looks right to me.  I am not sure that there is a need for a more
generic syntax.

> 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.

Even the recent one?  I started having more categories in command_data.txt
both for the inner commands classes (in_heading_spec) and outer commands classes
(contain_simple_text, contain_plain_text), maybe simply adding more
classes/flags would be enough to have a clear code.  The issue is that
the number of flags is constrained for the XS parser.

-- 
Pat