Named anchor references via /file URLs
(1.1) By Warren Young (wyoung) on 2020-09-19 18:37:56 edited from 1.0 [source]
If you visit this URL and click on the "modify the default CSP" link at the end of the introduction, you get sent to the expected section of the document, "Overriding the Default CSP".
If you visit the same document via this URL instead and click the same link, you apparently get sent to a different document, the top-level README.md file, but what's actually happening is that the URL tail is .../file#override instead of .../file/www/defcsp.md#override.
You can manually fix this up, inserting /www/defcsp.md into the URL after "file", but Fossil should be able to figure this out on its own.
Anticipating a likely objection, "Why don't you use embedded doc URLs, then?", I do, by preference, but someone may come across this file in a /dir view, click it, and then expect the internal named anchor links to work properly.
EDIT: Recast the examples in terms of Fossil's own docs, so that someone fixing this can test in-tree.
(2) By Stephan Beal (stephan) on 2020-09-19 19:42:00 in reply to 1.1 [link] [source]
Anticipating a likely objection, "Why don't you use embedded doc URLs, then?", I do, by preference, but someone may come across this file in a /dir view, click it, and then expect the internal named anchor links to work properly.
Coincidentally, i recently tripped over the difference between /doc and /file rendering, namely that links from /file renderings don't always work as perhaps would seem intuitive (and maybe can't, for lack of context), and that left me wondering whether /file view should completely disable the rendering of links as links (and instead maybe use a SPAN placeholder or some such, with the text but no link), and add a link across the top of the page which opens the that file via the /doc path.
i know those two features developed separately and serve different goals, but there is ostensibly a lot of overlap between them... except that /file doesn't render relative links like /doc does.
Case in point:
Doc: https://fossil.wanderinghorse.net/r/pikmojicon/doc/tip/pikchrs/symbols/
vs. the same doc viewed under /file:
File: https://fossil.wanderinghorse.net/r/pikmojicon/file?name=pikchrs/symbols/index.md&ci=tip
In the latter, the in-document links are all broken because they were written for /doc mode. Note that the former's links all refer to directories, which the docs then expect /doc to resolve to each directories' index.md. /file, OTOH, doesn't know that.
(3) By anonymous on 2020-09-22 03:40:00 in reply to 1.1 [link] [source]
This is due to /file view routing a file-path request using 'name=file-path' parameter.
However it's well capable to properly interpret the direct /file request (including the named anchor ). It seems that internally the link-base handling is being forced to use the "name=..." schema.
Also, the artifact view handles the named anchors properly, well, it routes the links to /doc.