[folding answers to two e-mails into one]
>> 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.
OK.
> 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.
Well, the behaviour of `@node` in a split HTML document is to start a
new file. However, this is exactly what I would like to avoid.
> If the node directions are implicit and menus are automatically
> generated, then @node directions and @menu are generated based on
> the associated sectioning command.
Understood, thanks. Actually, I missed the announcement some years
ago that `texi2any` can automatically create `@menu` blocks, which is
a huge and very useful simplification. I will eventually test that
with LilyPond.
> If @node becomes associated to @XXXheading command, there need to be
> a rule to have the automatic node directions take into account this
> node. [...] Menus can then be generated using the same rules as
> used for automatic node directions.
The thing is that I don't want a menu for `@XXXheading` elements (or
rather, I don't want HTML splitting for these commands)!
> [...] having an @-command more similar to an @anchor associated to
> an @XXXheading, or even to another sectioning command may still be a
> good idea. Indeed, it allows to have a node that contains
> sectioning or heading commands that can be handled more similarly to
> sectioning or heading commands associated to a node but in the same
> output unit.
Yes, exactly – in HTML split mode, `@anchorlabel` (or `@label`, which
I won't stop advertising :-) plus `@XXXheading` should be on the same
page as the last `@node` command.
Werner
