bug-texinfo
[Top][All Lists]
Advanced

[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: Thu, 19 Jan 2023 04:52:07 +0100

On Wed, Jan 18, 2023 at 09:30:53PM +0000, Gavin Smith wrote:
> I don't see why it should be a huge performance barrier.  Suppose
> we want to forbid nested @footnote; then we would have a hash like
> $self->{'nesting_context'} equal to {'footnote' => 0}, then when
> we enter a @footnote, we increment $self->{'nesting_context'}->{'footnote'},
> and decrement it on leaving.  Whenever we see a @footnote, we check that
> $self->{'nesting_context'}->{'footnote'} is equal to zero.  This approach
> would also work for nested cross-references.  It would not require traversing
> the list of currently open commands for every command.
> 
> For places where @anchor should be forbidden, we would use a counter like
> $self->{'nesting_context'}->{'simple_text'} to mark that @anchor is
> excluded throughout.  Increment it on entering a @chapter argument and
> decrement it at the end.
> 
> If there are other contexts where only a restricted subset of Texinfo
> commands is valid, these could expressed with similar counters.
> 
> Obviously I haven't tried to implement this, so there would likely be
> complications.  I would be willing to work on the XS parser code for this,
> as I have time, if it is agreed it is a good idea.

It is not completly clear to me that the performance cost would be lower
than looking at the commands stack and checking that the nesting is
valid, as there is, in general, no deep nesting, and the performance
penalty will probably be more important for your option when there are a
lot of non-nested commands.  Your proposal, however, avoids a performance
penalty increasing with nesting, as it would be simply proportional to
the number of commands, I believe.  I do not think that we can know
in advance which one is better, though, as it depends on the manual.

In any case, your proposal looks good to me, I can follow-up with
changes in the pure perl parser if you want me to.

-- 
Pat



reply via email to

[Prev in Thread] Current Thread [Next in Thread]