On Tue, Feb 18, 2025 at 04:04:45PM +0000, Gavin Smith wrote:
> On Tue, Feb 18, 2025 at 04:04:53PM +0100, [email protected] wrote:
> > On Mon, Feb 17, 2025 at 07:13:43PM +0000, Gavin Smith wrote:
> > > On Mon, Feb 17, 2025 at 07:37:23PM +0100, [email protected] wrote:
> > > The user could also specify "@xrefautomaticsectiontitle on" and
> > > "@xrefautomaticsectiontitle off" throughout the manual to get the
> > > desired effect.
> > >
> > > For links to anchors, the @xrefname would follow the @anchor:
> > >
> > > @anchor{Butterfly}@xrefname{Papilon}.
> >
> > I really dislike this possibility. For one thing, I think that an
> > inline version should be a different command. However, my feeling is that
> > having a separate command with both the anchor and associated name would
> > be better in term of consistency of the language. I think that
> > associating inline braced commands based on their relative location is
> > not something we should start doing unless we have used all the other
> > possibilities. Based on nesting is more ok, though it is also better to
> > avoid if possible.
>
> I question how anchors appearing immediately after nodes should be treated.
> For example (from texinfo.texi):
>
> @node Document Permissions
> @nodedescription Ensuring your manual is free.
> @anchor{Software Copying Permissions}@c old node name
> @section Document Permissions
>
> Here "Software Copying Permissions" is an alias for the "Document Permissions"
> node, so it would make sense for the @section line to be used for both
> under xrefautomaticsectiontitle. (I expect that this not what currently
> happens.)
>
> Then if we used @xrefname instead, then it would make sense that this
> should also provide the text for links to both the node and the anchor:
>
> @node Document Permissions
> @nodedescription Ensuring your manual is free.
> @anchor{Software Copying Permissions}@c old node name
> @xrefname Document Permissions
>
> Such @anchors, in between a @node and a sectioning command (or heading
> command, or @xrefname) could possibly be treated as a special case.
I think that it is too much special casing that would lead to unexpected
results and too much code to handle, since we could have instead a
simpler alternative, with a command like
@anchornamed{Software Copying Permissions, Document Permissions}@c old node name
For anchors added for removed nodes, I do not think that we should
try to have anything special done, as anchors added for removed nodes
should not be used as soon as possible, if it just works it should be
enough. There could be other use cases, though, probably, when there is
a legitimate reason to have two names for a @node in the long run. But
even in that case, I think that something like @anchornamed{. , .} would
be better.
--
Pat
