-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Allow linking to sections from summary #167
Comments
To have a little more context here, what would be the use case for this feature? |
Sections A and B for which both of the following are true:
|
I assume this requirement is for the Serde book? Particularly, here is where it is used currently. I do see the appeal for such a feature, but there are some drawbacks too.
Getting this right seems to be more complicated than it might appear. When you scroll to the sub-section the sidebar has to update the current chapter (= blue highlight) and the url should be updated accordingly to allow for easy linking. Gitbook handles this well. But this feature seems to break the keyboard navigation in Gitbook. |
My summary no longer includes any links to sections so I would not use this. Thanks for checking. |
I'm still very interested in this feature! At the very least, I would recommend to throw an error with a link to this issue when trying to I have very little Rust experience so far (front end dev primarily), but can I potentially help with this? Would this feature be appreciated / accepted to begin with? |
Hi All, I did an implementation for this case (the PR is already pointing to this issue), I saw in this issue some concern about this support, that I'm willing to tackle :). First:
The current implementation does not do any check, but I could definitely do checks that verify that a "link.md#anchor" is a child of the "link.md" in the Toc hierarchy if this make sense for everyone.
This make sense following the previous argument, I can also add this check if this is the expected behaviour.
This is already tackled in the current implementation in the PR even though it actually impact the preprocess communication format, so an outdated pre-processor will actually strip out the anchor from the Toc. Just asking for a feedback to see fi make more sense to push forward with the checks or if anyone see any other roadblocks. Regards |
This would break compatibility with other tools such as GitBook and GitHub which both require the full path before the anchor. |
We would like to see this supported, or at minimum an error thrown when trying to do this. It is quite counterintuitive to use markdown link syntax for the summary but then treat foo as a link to a file |
Any update on this, it would be quite handy... |
I am still interested in this issue as well. Is there any progress? |
apparently it is not possible to link to page anchors with `mdBook`[1] [1]: rust-lang/mdBook#167
apparently it is not possible to link to page anchors with `mdBook`[1] [1]: rust-lang/mdBook#167
If I'm understanding this restriction correctly, no-anchors-in-summary makes re-organizing a chapter onerous, due to the necessity of managing sections as files. That I can work with; but it also forces each section into a separate (potentially artificially small) page. I would love to be able to say this:
...and have an anchor point to e.g. ./ch-big.md#abigsection. |
…ons from the summary. rust-lang/mdBook#167
I suspect this would not be easy to add. Currently, it seems This mapping makes it easy to highlight the relevant TOC item based on a reverse-lookup of the filename. To have multiple anchors mapping to different TOC items, you'd need M : 1. That means it is no longer possible to pin-point the TOC item purely based on the filename. Same situation with mapping multiple TOC items to the same file. |
I got stuck with the same issue today. Ended up simply redirecting:
In
|
It's 6 years. Are we even getting this? |
I didn't want to create a ref in |
happy new year! has there been any consensus on how this should implemented or if it will be implemented? or workarounds? |
apparently it is not possible to link to page anchors with `mdBook`[1] [1]: rust-lang/mdBook#167
Any updates or any workaround? |
apparently it is not possible to link to page anchors with `mdBook`[1] [1]: rust-lang/mdBook#167
@lapk-arista out here doing gods work |
In SUMMARY.md I have a link to a section like
[Section header](page-title.md#section-header)
. This works in GitBook but mdBook creates empty filespage-title.md#section-header
andbook/page-title.md#section-header
(file names containing#
).The text was updated successfully, but these errors were encountered: