Inconsistent anchor-id linkage

[KrishnaPG]

While trying to render markdown docs from github getting inconsistent anchor / link combinations (due to the header ids being forced to lowercase ). For an example, below is one such doc:

# Introduction

- [Introduction](Introduction),
  - [Reproducible research](#Reproducible-research)
  - [We need better tools!](#We-need-better-tools!)
  - [Introducing psychopy_ext](#Introducing-psychopy_ext)

## Reproducible research

So far we've discussed how to code experiments. But research is more than just making an experiment! You have to analyze data, possibly also compare them to simulated data, present them in conferences and publish in journals

## We need better tools!

I do not blame researchers for relying on all these ad-hoc solutions. While in theory it would be nice to code everything from A to Z, in practice we don't have the time to play these silly games. Why we don't have the time is a topic for a separate discussion, but why we have to play these silly games is the problem of software. Simply put, we the lack tools that would seamlessly enact good coding and sharing standards. We need **tools that act clever**.

The generated header ids are all forced lower case, while the generated a href links are retained "as-is".

• Please add an option to control the casing for all generated header ids and internal hrefs (to either use "same case" or force lowercase).

• or, consistently force the same casing for all generated internal link `hrefs` and anchor ids,
  

• or, when user explicitly specifies an internal link (as above) anywhere in the markup, ensure that generated ids are consistent with user expectations (without changing the case anywhere).
  

Forcing the lowercase only for header ids, while leaving the <a href "as-is" is causing un-navigatable docs to be rendered.

[Feder1co5oave]

Auto-generated header IDs is a much discussed topic for marked, so any change to the current default behavior is going to upset some people.
The official suggestion is to never rely on the IDs generated by the default renderer and create one of your own that suits your needs.
For you, the following should do.

renderer = new marked.Renderer;
renderer.heading = function(text, level, raw) {
  return '<h'
    + level
    + ' id="'
    + this.options.headerPrefix
    + raw.replace(/[^\w]+/g, '-')
    + '">'
    + text
    + '</h'
    + level
    + '>\n';
};
html = marked(src, { renderer: renderer });

[KrishnaPG]

Thank you. Your code snippet is helpful.

However, the problem is not as much about the the exact IDs generated, as it is about consistency between the ID and the internal a href anchors

When the document authors specify explicit header IDs, they inevitably use them in the anchor tags (for example, to generate TOC). So, creating custom renderers with custom IDs as you have suggested will break the document.

For example, consider this line I sampled from one of the document TOCs:

    "  - [We need better tools!](#We-need-better-tools!)\n",
    "  - [Introducing psychopy_ext](#Introducing-psychopy_ext)\n",

Unless the header We need better tools! gets the same ID #We-need-better-tools!, the TOC is broke and document becomes unnavigatable.

The solution is not to customize the header generation, but to use explicit IDs (if supplied by the author) as is, without customizing them further.

If the author supplied explicit IDs, there must be a good reason why he did so. For all that we know, the author might even share that link somewhere outside externally and we should be able to resolve it correctly. Using our own transformations on the headers, will break such documents.

[Feder1co5oave]

You speak about explicit IDs for headers, but

1. you don't explain how these explicit IDs should be specified by the author
2. marked does not support such a thing right now
3. AFAIK plain markdown does not envision this feature (nor does commonmark)