On Fri, Feb 14, 2025 at 02:59:45PM +0000, Werner LEMBERG wrote: > >> Well, I think that your `@anchorlabel` suggestion is the way to go. > >> Actually, I would prefer a shorter name, say, `@label`. Then you > >> can demote > >> > >> ``` > >> @node Foo > >> @subsection Foo doodle doo > >> ``` > >> > >> to > >> > >> ``` > >> @label Foo > >> @subsubheading Foo doodle doo > >> ``` > > > > I still can't see why > > > > @node Foo > > @subsubheading Foo doodle doo > > > > would not work too. > > Because in Info a `@node` always needs a `@menu` entry, AFAIK, which > is inconsistent with the `@XXXheading` behaviour.
The @node directions and @menu entries, if explicit, are, in principle, fully independent from sectioning commands such as @*section and other. So, this is not different if a @node is before an @XXXheading, it may appear in an explicit node direction and in another @node menu. If the node directions are implicit and menus are automatically generated, then @node directions and @menu are generated based on the associated sectioning command. If @node becomes associated to @XXXheading command, there need to be a rule to have the automatic node directions take into account this node. But it seems to me that it can be solved, for instance, a node associated to an @XXXheading could be considered to be right below the previous non-XXXheading sectioning command. This would probably complexify the structuring code, for example by adding another set of sectioning commands direction with @XXXheading commands associated to @node taken into account in those directions. Menus can then be generated using the same rules as used for automatic node directions. -- Pat
