-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Support in-repo links, with verification and output-dependent conversion #431
Comments
By the way, a side benefit of this is that the links will work in github rendering of the MD files, allowing easier source view and transition between pages. |
I'm absolutely voting for this issue. I definitely want people to be able to browse the markdown files easily on github with all link pointing to the respective markdown files. The disadvantage of my approach is that I need the exact same structure in the SUMMARY.md that I have on the filesystem. A proper solution should map those paths correctly, so that the fs structure and book structure can be different. If anyone is interested, this is the relevant part of the script: mkdir -p build-dir
cp -r src build-dir
cd build-dir/src
for f in **/*.md; do
if [ $f == "SUMMARY.md" ]; then
continue
fi
dir=`dirname $f`
sed -i "s/\(\](\|]: \)\([^\/][a-zA-Z\.\/\-]\+\)\.md\(#[a-z]\+)\?\)\?/\1${dir//\//\\\/}\/\2\.html\3/g" $f
done
cd ..
$MDBOOK build
rm -r ../book
mv book ..
cd ..
rm -r build-dir |
We're pretty much done extracting out the preprocessing into its own stage (#532), and once that lands it shouldn't be long before we have a proper solution which can understand the book structure. This is an issue which annoys me as well, so I'm keen to deal with it before the next release! My mdbook-linkcheck backend includes a check for the exact case where you use a
The HTML renderer replicates the source file structure when rendering (technically reusing the chapter's path field), so while it's still implementation-defined behaviour you should be okay with what you're doing at the moment. |
Any updates or workarounds for this? We currently suffer as well from this issue :-( |
I thought this was implemented already? I know that the rustc-dev-guide uses |
We had to work around by naming them |
For anyone who comes across this in the future: |
Linking to md files works, and it seems mdbook has settled on using README.md as the source name for index.html.
Perhaps those two should be split into their own issues and this one closed? |
@tv42, it's documented under the
You are correct. The I believe The Rust Programming Language uses its own script for validating links, while a fair few other projects use the |
Ah, the |
And if the project has decided link checking will not be part of the core, then that sounds like this issue is done (barring the wish for better & discoverable documentation). |
|
Any updates? |
Is there a chance that this decision is revisited? Consistency enforcement should be a core feature, not a plugin. |
While updating the new Cargo manual and preparing it for a release, I realized one big part of the work I was doing was to make sure the internal links are valid, after moving many pages around.
This made me realize that we don't have link verification for in-repo links, and partly it's because of the fact that the MD source files are linking to the HTML output files, but not to the respective MD source files.
Also, there's the fact that if there's ever any other output type, the internal links will be broken.
So, wondering if supporting in-repo links as link-to-source, plus link verification and output-dependent conversion, is something that's already in the plans for mdbook.
Example
Input
index.md
This would error if
first/index.md
doesn't exist.Output
If no errors, it converts the link to the HTML file.
index.html
The text was updated successfully, but these errors were encountered: