-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try to ensure all internal links are relative #593
Conversation
Fixes #581 Relative paths _should_ always work, whether viewing docs as a file or via a web server, either locally or online
* master: Handle entities that might not have be correlated in resolving links
d99fda0
to
09f26d8
Compare
Hi, thanks for this. Unfortunately, this doesn't seem to be enough. It seems that links are now properly resolved (as in, the target has the correct path), but most of them are still absolute for me. In particular, the ones in the root |
Ah yes, ok, I think that should be an easy fix. I didn't manage to get a decent test for checking for absolute paths. |
I'm thinking, wouldn't it be much simpler to forgo absolute paths altogether, and use absolute URLs for internal link (i.e. |
Yes, I had considered this previously, and decided against it as Sphinx seems to prefer to always use relative links and so doesn't require using a web server. It would definitely simplify things, at the cost of an extra step to view pages locally. |
This seems to be a better and more consistent way than trying to filter each link individually
Finally got round to finishing this off. Instead of trying to fix each link individually, we now just replace absolute paths in links when rendering each page. This should (hopefully!) now capture everything in one go basically. |
Thanks a lot for this. This is indeed a much more robust strategy. It seems to be working, with one exception: links inside images are still absolute on the home page. I have As an additional note, there seems to be a significant performance hit with this strategy. Without search and graph features, it took about 10 s to generate the documentation of our project before this change (similar times on ford 6), and it takes now about 1 minute (5 s in parsing, 0 s in processing, 49 s to write files). This is the documentation without the graph and search features (that add another 3 minutes or so to the build time). I would much rather have a slow code that produces the expected result than a fast code that produces something we can't use, so I don't think this is a blocking problem, but I thought this is worth mentioning here anyway. EDIT: the search bar also sends me to |
I think that will be fixed by #608 as the alias expansion will be done earlier, and then caught by the markdown relative-link processor.
Hmm, I was a bit worried about that, and that's much worse than I was expecting from my limited tests. I might try a different tack and see if that fares better. At least we have this implementation to fall back to. |
Mmm, I rebased the Also in case you haven't seen the edit in my previous comment, the search bar (from anywhere) sends me to |
Replaced by #609 |
This seems to avoid more problems than optionally having links be absolute.
Fixes #581