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

[Patrice Dumas]

On Wed, Jan 18, 2023 at 08:54:21PM +0000, Gavin Smith wrote:
> On Wed, Jan 18, 2023 at 11:52:33AM +0100, Patrice Dumas wrote:
> > 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.
> 
> If it would help simplify matters we could add space for more flags in
> the XS parser.  We would just have to add another field to the COMMAND
> structure: "unsigned long flags2" for another 32 flags.  We'd also
> need a new macro to access the flags, likely command_flags2, and
> a naming scheme for the flag symbols, e.g. with a CF2_ prefix.  It
> may also be possible to use a 64-bit integer type.
> 
> It's nice to limit the number of flags for the sake of simplicity alone,
> but this is not an absolute requirement.

Ok.

> However, there are already unused flags in commands.h: currently,
> CF_item_container, CF_item_line, and CF_inline.  Would there be any
> reason not to delete these now from commands.h?  I feel this would be
> a good idea to make it clear that they are no longer relevant.

I agree.

> There are also some flags that are not used in the XS code, like
> CF_letter_no_arg, and there might be the scope not to generate these
> in command_data.c.  command_data.awk already omits a list of flags
> not used in the XS code.

Some of those flags could become useful, and most probably would allow
to have a code more similar to the pure perl parser, if the pure perl
parser code is found to be clearer for that case.  So I would suggest
keeping the flags that can become useful, as is the case for
CF_letter_no_arg even if they are not used.

-- 
Pat