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
