adityak368
Add Opt-In GitHub-Compatible Heading ID Generation to TOC Extension
Problem feature would solve: Users want Markdown heading ids that match GitHub-style anchors when using the toc extension. Today toc uses its default slugify which differs on underscores, punctuation, Unicode normalization, and duplicate handling. Add an opt-in mode so inputs like "A_B C-D!" yield ids identical to GitHub such as "a-b-c-d", with stable numeric suffixes for duplicates.
Proposed solution: Add an optional config key for the toc extension: id_strategy with values "default" (current behavior) or "github". When "github", generate ids with a GitHub-like slugifier: lowercase; Unicode NFKD; drop combining marks; remove non-alphanumerics except hyphen; map spaces and underscores to hyphen; collapse repeated hyphens; trim leading and trailing hyphens. Handle duplicates by suffixing "-1", "-2", etc., in document order. Precedence rules: an explicit id on the heading wins; if a user supplies a slugify callable, it overrides id_strategy; otherwise use the selected strategy. Only ids and matching internal href targets change; permalink HTML and list structure remain unchanged. If id_strategy is provided with an unsupported value, raise ValueError and include "id_strategy" in the message.
You can already use other slugify options if desired or write your own (I have my own that I use here).
The one thing that you cannot control is the duplicate separator. I've never quite understood why the separator option doesn't change the duplicate separator. But I do know that suddenly changing it as the default now would break a lot of things.
If there is one thing that I personally wouldn't mind if it changed, it would be the ability to control the duplicate separator. It's a small thing, and I've lived with how it is for a long time, but I wouldn't mind having the option to have it be -.
As mentioned, it is already possible to provide your own slugify implementation. Therefore, there is no need to make any additional changes.
I've never quite understood why the separator option doesn't change the duplicate separator.
It was a long time ago and I can't be absolutely certain, but in all likelihood, it was an oversight. It simply didn't occur to me at the time to connect the two.
But I do know that suddenly changing it as the default now would break a lot of things.
Exactly. That said, I am not opposed to providing a way to override it in a backward compatible way; whatever that may look like. I'm willing to leave this issue open on that narrow issue only. However, if noone pursues it, then I'll close this issue as wontfix.
