Re: permanent links using #fragment names

[Gavin Smith]

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?

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

> Instead, I suggest that the primary and visible name for every node and anchor
> use the fragment names (the part after the '#').
> 
> For example, the Keys chapter in the Emacs manual would still be in the
> file Keys.html, and you can still browse to 
> "https://whatever/emacs/Keys.html";.
> However, the "perma-link" would be "https://whatever/emacs#Keys";, and that
> is what would show in the location bar.  Currently, 'Keys" is a section,
> but the perma-link would remain "emacs#Keys" regardless of whether
> it is changed to a chapter or subsection, or of the splitting mode.
> Even if the section is renamed, "emacs#Keys" would work as long as
> an @anchor with the old name is added.

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

> Implementing this would be trivial in info.js - it already does this
> for file: URLs.  That is assuming that info.js can map the fragment
> name to the correct file.  Currently, this is done by looking
> in the "contents" element in the initial index.html.  To handle
> other anchors (not in the contents) I propose texti2any can add them
> to the contents as invisible element.  Perhaps:
>   <span id="toc-Using-Foo" data-location="Foo.html#Using-Foo" 
> data-toc="subheading" data-title="Using Foo"/>
> 
> 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?

> An optional-but-nice refinement: When scrolling in a page, update the 
> location bar
> *and* the side-bar.

Yes, completely agree.  Look at

https://domterm.org/Input-line-editing.html

As you scroll the page the sidebar is not updated.

See https://www.britannica.com/place/Portugal for an example of
an updated sidebar (if it lets you see that page), although I don't
find that page works perfectly.  You can also see the URL changing
as you scroll (e.g. to https://www.britannica.com/place/Portugal/Climate).

> Note this doesn't have to be something we force on users: We can still 
> generate
> the extra stub files, and we can make it a preference in info.js whether
> to prefer the emacs#Keys style in the location bar.