On Sun, Feb 16, 2025 at 12:57:21PM +0100, pertu...@free.fr wrote:
> On Sat, Feb 15, 2025 at 04:38:34PM +0000, Gavin Smith wrote:
> > On Sat, Feb 15, 2025 at 01:16:13PM +0000, Werner LEMBERG wrote:
> > >
> > > [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.
> >
> > Yes, as far as I can tell the primary purpose of @node is to define
> > units of output. In Info output, these are Info nodes. In split HTML
> > output, these are files.
>
> This is only true if USE_NODES=1. For HTML, if USE_NODES=0, the
> sectioning commands define units of output and @node are only
> used ase targets of cross-references.
What would be the advantage to a user of setting USE_NODES=0?
> > So what I am thinking now is that we would allow and encourage
> > multiple section or heading commands within single @node. For example,
>
> We already allow for that and we do not discourage.
You wouldn't get an idea it was possible from reading the Texinfo manual
or from looking at most Texinfo source files. Usually, when a file has
@section or @subsection without a preceding @node, it is a mistake and
the author meant to write @heading or @subheading instead.
> There is also the idea that the following would lead to @label
> associated to @heading, and not @section, as is the case now for @node:
>
> @label Heading 1
> @heading heading one
>
> @section a section
Yes, I agree. For simplicity @label and @node should work the same way
here.
> > This would be enough for your needs, as far as I can tell, but in case
> > we also wanted "xrefauto'ed" links to arbitrary locations, not just
> > headings, then we'd need to extend @anchor as discussed elsewhere in this
> > discussion:
> >
> > @table @asis
> > @item Papilon@namedanchor{Butterfly, Papilon}
> > ...
> > @end table
> >
> > (This follows Patrice's suggestion.)
> >
> > Then the "anchor name" would be "Butterfly"; the name for cross-references
> > would be "Papilon". (I'm not sure how to refer to the name for
> > cross-references as both "name" and "label" are confusing terms. The
> > "refname"?)
>
> Maybe we could wait for actual use cases before implementing this?
Yes and we could take more time to design the feature.
