Re: Info enhancements

[karl@freefriends.org (Karl Berry)]

Responding now to Luc's mail about @anchor in general.

    If anchors are actually preferred over node names, 

I would not say that anchors are "preferred" over names.  Ultimately,
there is a bias in Texinfo toward reasonably short nodes.  When the
nodes are short, subnode positioning does not matter.  Thus, @anchor was
not available in Texinfo for many years -- and thus was not used in most
existing manuals, which predate the feature.

On the other hand, anchors are there to be used, there's no reason to
hesitate about it at this point.

    Or one might give some guidelines on _when_ to use @anchor.

I agree.  From this discussion, the answer forming in my mind is "when
you have a long node, and want to go to an exact location within it".

And I would also say "consider splitting such a long node into several
subnodes" -- but I realize there are cases where that is not desirable.

    A reference would lead in a random way either to the top of the node
    or to the "correct place".

If there were more anchors, users would simply get to the "correct"
place more often.  That's all to the good.

You're right that naming conventions could distinguish, but I'm not sure
that's completely the way to go either.  An xref label like
"file-coding-system-alist" seems perfectly reasonable to me; it is
not apparent whether it is a node or an anchor, but as long as the user
ends up at the description of file-coding-system-alist when they follow
a reference, I don't think it matters.

A couple of sentences in Help-Xref couldn't hurt.

Thanks,
k