Re: permanent links using #fragment names

[Per Bothner]

On 1/9/22 10:28, Gavin Smith wrote:
> On Sun, Jan 09, 2022 at 09:32:38AM -0800, Per Bothner wrote:
> > An idea I've been mulling: Currently, we handle changes in node structure
> > by generating extra stub pages that redirect to the correct location.
> > This works, but it's a bit clunky.  For one thing, it doesn't update
> > the location bar (though that could be fixed).  Worse, it highlights a
> > two-level name hierarchy FILENAME.html#FRAGMENT that depends on
> > the splitting mode.
>
> When you say "changes in node structure" does this refer to changing
> the splitting setting?

That too, but I was including changing the texi source to (say) split
a chapter into sections, or change subsections to separate sections.

> Renamed @node's in a document are often marked with @anchor's, which
> may have their own redirection pages - is that what you mean?

In part.

> Can this be done without JavaScript or is it only for info.js?

If the manual is not split, then JavaScript would not be needed.
Otherwise, JavaScript would be needed to resolve a fragment id
to load the correct page.  However, one could generate in the ToC
something like:
  <li id="Keys">See <a href="Keys.html">Keys</a></li>
That way, a link like "emacs#Key" would scroll to a link that
the user could click.  If JavaScript is enabled, we could hide that
link, or format it appropriately for the sidebar.

One could also do the opposite: Generate every anchor/node name Foo
as Foo.html. If Foo.html is only a re-direction page, the JavaScript
could optimize that.

However, there is an argument that ".html" is non-semantic
implementation information that should not appear in putlic URLs.
It is similar to a ".php" extension exposing implementation
information.  That is why "emacs#Keys" is better than to "emacs/Keys.html".

> > Note this would also help with the issue discussed in the
> > "control over sectioning and splitting" thread, since info.js
> > could optionally put subheading (for example) in the side-bar.
>
> I don't really understand the benefits of listing @anchor's (invisibly)
> in the table of contents in index.html.
>
> Somebody opens a redirection page for an anchor, at some point info.js
> gets loaded and the page URL is changed to the correct location.  Is
> a list of the anchors in index.html needed for this?

We want URLs (the ones that are visible publicly or externally)
to look the same whether it's an @anchor, a page-level @node
(i.e. @chapter if splitting by section), or a sub-page-level @node (a 
@subsection
if splitting by section).

You can do that by making all public URLs have the form #NAME or all
URLs have the form #NAME.html. The former is shorter, more elegant,
more semantic - and doesn't hard-wire the use of html format.

If you use #NAME for your public URLs you'd like to automatically
map that to the correct location in the correct file - without
having to first load and parse all the pages. You avoid that
by having the mapping from #NAME to location somewhere on the home page.

--
        --Per Bothner
per@bothner.com   http://per.bothner.com/