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.
