Re 135: separate indexing and linking by heading depths to keep rewriting id based links #139
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates to #135.
In #135 and #136 we introduced a new option
linking.headingDepths
. The previous implementation would exclude headings at a depth not covered by the config from indexing. As a consequence there were no links created anymore for term-based auto linking - as expected - but as a side effect any explicit id-based cross-links[foo](#heading-id)
would also not get their paths resolved anymore - which might be unexpected AND unwanted.For example as a writer I may want the system to create less links out of term-based auto linking while still be able to decide when to have an explicit id-based cross-link.
To accomodate for such scenario this PR introduces an additional option
indexing.headingDepths
which by default will index headings at depths[1,2,3,4,5,6]
, so they can still be used in id-based cross-linking andlinking.headingDepths
will now only affect term-based auto linking. For reasons of backwards compatibility the default here is[2,3,4,5,6]
so there won't be auto links for page titles by default.