Re: runaway recursion in makeinfo

[Patrice Dumas]

On Mon, Nov 21, 2022 at 01:42:20PM -0800, David Bacon wrote:
> But I like such constructs!  I have one in every one of the 249 @section
> commands in the document I originally submitted with the bug report.  They
> are there so that the Table of Contents in the PDF has a nice link from the
> name of the operator or function to the right place in the document (not
> just to the page number, which is a tiny adventitious thing off to the
> right from the point of view of someone who is reading the PDF document
> online, and then only takes you to the top of the right page).

As Gavin said, it is better to have it as a feature of the output.  It
is the case for HTML, I checked that the LaTeX output is also like that,
and the table of contents should not be used in Info.

> They're not
> really "self"-references, just references to the corresponding nodes, and
> until quite recently, I'm sure I was able to use them.

That's because the nodes were used until 6.8 for the @ref, in 6.8
NEWS:
      . use section names in links by default (configure with
        xrefautomaticsectiontitle customization variable)

With xrefautomaticsectiontitle on, they become self-references.

> Why would you want
> to forbid them?  Is there a fundamental semantic problem with them, or just
> an implementation inconvenience?

A section referring to the associated node seems semantically wrong to
me, as a node and the associated section, in the traditionally
structured manual are either:
* two parallel possibilities of referring to the same element that contains
  both, with one or the other used depending on the format
* or a title (the section) and its label (the node).
The semantics of Texinfo are not rigid, so it could be considered
differently, but in the normal case, a section referring to its node, is
like a title referring to the associated label, which is very strange,
the label should be used instead to refer to the title and the title
should not refer to anything.

In term of implementation, it could indeed be solved in the converters.
But risking having a converter going into such an infinite loop seems
wrong to me.  Reference to node actually leading to the section is a
logical setup in the label/title semantics and could be used in many
converters.

The double recursion case does not seem to me to be semantically
incorrect.  It is somewhat strange to refer to another node in a
section, but it could make sense and be interpreted as referring to the
section associated to the node.  However, to avoid a risk of loop in a
converter, I would again propose to break the loop directly in the tree.
There could be a customization variable to allow the loops.

-- 
Pat