-
Notifications
You must be signed in to change notification settings - Fork 86
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
Anchor links in generated markdown are not unique #300
Comments
There is [a bug in puppet strings][] that makes anchors non-unique. This particularly affects parameter names, because many of them are shared by multiple resources. This adds a script that rewrites REFERENCE.md to make the anchor names to be more likely to be unique. [a bug in puppet strings]: puppetlabs/puppet-strings#300
There is [a bug in puppet strings][] that makes anchors non-unique. This particularly affects parameter names, because many of them are shared by multiple resources. This adds a script that rewrites REFERENCE.md to make the anchor names to be more likely to be unique. [a bug in puppet strings]: puppetlabs/puppet-strings#300
Hey buddy! Interestingly, the anchors appears to be created at https://github.com/danielparks/puppet-rustup/blob/f405dac71b966d875b0d2e96984b0a2166032fcf/REFERENCE.md#ensure-1, but the link to it doesn't keep the index |
Hey Ben! Been awhile! I think that’s an artifact of GitHub generating the HTML. Looks like it appends a number onto each successive anchor, but as you say, it doesn’t fix the links (presumably it would have to guess). Looks like Forge does basically the same thing, though it also doesn’t fix the links. Probably it makes sense to look at the underlying markdown: https://raw.githubusercontent.com/danielparks/puppet-rustup/f405dac71b966d875b0d2e96984b0a2166032fcf/REFERENCE.md I actually fixed this (mostly) with post-processing: https://github.com/danielparks/puppet-rustup/pull/15/files#diff-1aacbb5834541d8fb2daa76bafbe0339f4f637bdea56c4c6411fe5d29c603995 In retrospect, maybe the issue “anchor links not unique” is too large — to deal with all the (uncommon) cases you basically have to construct a big index as you go and make sure you’re referring to the right one — or, make some sort of reversible encoding that supports whatever characters are allowed in an anchor. The script I linked above is a giant hack but it probably deals with the vast majority of cases that don’t involve type names like
You can see the results in GitHub HTML and raw Markdown. |
I made a few improvements to my script. I’m pretty sure it’s impossible for it to generate non-unique anchor names, but I’m not 100%. |
Previously, anchors in generated Markdown were not unique. There were two problems: 1. Each parameter in a class, type, function, etc. had its own anchor, but the `name` of the anchor was just the normalized name of the parameter. This meant that all parameters with the same name would have the same anchor. 2. Classes, types, etc. had their `::`s removed, whiched opened the (rare) possibility of having non-unique anchor names for unique type names. This fixes those problems by: 1. TODO: Using the full name of the parameter, e.g. `$my::class::param`, to generate an anchor name. 2. Using a better anchor normalization routine. Each invalid character, i.e. not `\[a-zA-Z0-9_-\]`, is converted to `-`. This should always result in unique anchor names for standard Puppet identifiers, since the onlid invalid characters sequences are `::` and `$`, and `-` never appears.
Previously, anchors in generated Markdown were not unique. There were two problems: 1. Each parameter in a class, type, function, etc. had its own anchor, but the `name` of the anchor was just the normalized name of the parameter. This meant that all parameters with the same name would have the same anchor. 2. Classes, types, etc. had their `::`s removed, whiched opened the (rare) possibility of having non-unique anchor names for unique type names. This fixes those problems by: 1. TODO: Using the full name of the parameter, e.g. `$my::class::param`, to generate an anchor name. 2. Using a better anchor normalization routine. Each invalid character, i.e. not `[a-zA-Z0-9_-]`, is converted to `-`. This should always result in unique anchor names for standard Puppet identifiers, since the onlid invalid characters sequences are `::` and `$`, and `-` never appears.
Previously, anchors in generated Markdown were not unique. There were two problems: 1. Each parameter in a class, type, function, etc. had its own anchor, but the `name` of the anchor was just the normalized name of the parameter. This meant that all parameters with the same name would have the same anchor. 2. Classes, types, etc. had their `::`s removed, whiched opened the (rare) possibility of having non-unique anchor names for unique type names. This fixes those problems by: 1. Using the full name of the parameter, e.g. `$my::class::param`, to generate an anchor name. 2. Using a better anchor normalization routine. Each invalid character, i.e. not `[a-zA-Z0-9_-]`, is converted to `-`. This should always result in unique anchor names for standard Puppet identifiers, since the only invalid characters sequences are `::` and `$` (which only appears once at the beginning of the string). Furthermore, `-` never appears in a valid Puppet identifier, so those two cases are the only way for it to be generated.
Previously, anchors in generated Markdown were not unique. There were two problems: 1. Each parameter in a class, type, function, etc. had its own anchor, but the `name` of the anchor was just the normalized name of the parameter. This meant that all parameters with the same name would have the same anchor. 2. Classes, types, etc. had their `::`s removed, whiched opened the (rare) possibility of having non-unique anchor names for unique type names. This fixes those problems by: 1. Using the full name of the parameter, e.g. `$my::class::param`, to generate an anchor name. 2. Using a better anchor normalization routine. Each invalid character, i.e. not `[a-zA-Z0-9_-]`, is converted to `-`. This should always result in unique anchor names for standard Puppet identifiers, since the only invalid characters sequences are `::` and `$` (which only appears once at the beginning of the string). Furthermore, `-` never appears in a valid Puppet identifier, so those two cases are the only way for it to be generated.
Previously, anchors in generated Markdown were not unique. There were two problems: 1. Each parameter in a class, type, function, etc. had its own anchor, but the `name` of the anchor was just the normalized name of the parameter. This meant that all parameters with the same name would have the same anchor. 2. Classes, types, etc. had their `::`s removed, whiched opened the (rare) possibility of having non-unique anchor names for unique type names. This fixes those problems by: 1. Using the full name of the parameter, e.g. `$my::class::param`, to generate an anchor name. 2. Using a better anchor normalization routine. Each invalid character, i.e. not `[a-zA-Z0-9_-]`, is converted to `-`. This should always result in unique anchor names for standard Puppet identifiers, since the only invalid characters sequences are `::` and `$` (which only appears once at the beginning of the string). Furthermore, `-` never appears in a valid Puppet identifier, so those two cases are the only way for it to be generated.
(#300) Fix anchor links in Markdown docs
Fixed in #300 - Thank you @danielparks |
Describe the Bug
The anchor names in markdown generated documentation for a module are not unique. This is a particular problem for attributes such as
ensure
. Each attribute with the same name is given the same anchor link name, which breaks linking.For example, see the docs for my
rustup
defined type. Theensure
attribute links to #ensure, but the browser (Safari, in my case) can’t distinguish between theensure
attribute for therustup::global
class and therustup
defined type.You can also conflicting anchor names for types as well, since it just ignores characters like
:
.Expected Behavior
All anchor names should be unique.
Steps to Reproduce
Environment
The text was updated successfully, but these errors were encountered: