[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Texinfo command nesting and syntax checking: nested @ref
From: |
Patrice Dumas |
Subject: |
Re: Texinfo command nesting and syntax checking: nested @ref |
Date: |
Wed, 18 Jan 2023 11:52:33 +0100 |
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
- Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/17
- Re: Texinfo command nesting and syntax checking: nested @ref,
Patrice Dumas <=
- 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
- Re: Texinfo command nesting and syntax checking: nested @ref, Gavin Smith, 2023/01/29