Crop large anchor ID's

[Naatan]

This is an example of a generated anchor ID on the wiki I'm working on:

Manual/prefs#preferences_editor-preferences_smart-editing_configuring-word-or-character-wrap

It's veeery long, too long. Could this be handled more intelligently? eg. it seems to be including all parent headers in the anchor, this seems unnecessary. Additionally it would be nice if we could force a max length for these anchors, and have it crop if the max length is reached.

I understand the main reason for this is to ensure the anchor is unique, but you could also generate a hash based on the current information used and append this.

Far as I'm aware these hashes don't affect SEO, so there should be no concerns there.

[dometto]

I understand the main reason for this is to ensure the anchor is unique, but you could also generate a hash based on the current information used and append this.

That would make it more difficult for a human to link to a section though...

[Naatan]

I'm not saying the hash becomes the anchor. I'm saying the anchor is the name of the header (just the one its linking to, not its parents) and a hash is appended to ensure it's unique.

[dometto]

It appears github just uses the title of the (sub)heading and appends an index to it when there are possible conflicts. For instance, if there are two sections called use-spaces-in-filenames the generated anchors will be:

• #use-spaces-in-filenames
• #use-space-in-filesnames-1

Does that seem like a reasonable approach?

[dometto]

Also see gollum/gollum#1261

[dometto]

Fixed in 5.x (see here)