Alternative way to make anchor_link_text configurable

[takluyver]

Closes gh-412, alternative to gh-520

[takluyver]

@michaelpacer I think this is the main difference from #508: rather than passing the new option through the template to the existing filter, I've replaced the markdown2html filter with one that follows the config option.

[akashdeep1995]

@takluyver Hello. I am still struggling with getting rid of Pilcrow sign from Markdown Headings in Jupyter NB. I have followed up on your suggested solution and all conversations related to this issue. I accessed the html.py (Exporters folder) and strings.py and markdown_mistune.py (Filters folder) under nbconvert, and attempted a hack by replacing the Unicode for Pilcrow with the Unicode for space ' ' = u'\u0020'. I saved the files, then I tried to execute the following code snippets in my main Jupyter Notebook

`import traitlets
from traitlets.config import Config
c=Config()
c.HTMLExporter.anchor_link_text=u'\0020'

import nbconvert
import mistune
nbconvert.filters.markdown_mistune.IPythonRenderer.header=mistune.Renderer.header`

However, there seems to be no change and the Pilcrows are still crowding against markdown headings in my Notebook.

Your solution seems to be the only suggestion available online for this issue, urge you to kindly help me with any bright ideas on this. I desperately need to get rid of that symbol, then my nbconvert pdf conversion will be successful and presentable.

Thanks.

[mpacer]

One of the features that I don't like about this is that it puts a filter inside the html exporter. This would mean for someone who wanted to grab the filter from nbconvert, they would need to know to go to the exporter to find the filter as opposed to the nbconvert.filters. But if someone were to try to find a filter, we generally would point them to the filters module. Then, someone trying to use markdown2html as it exists in the filters module may suddenly have different behaviour than what they expected if they thought they were using the filter used by the html exporter.

I think we do have filters that are defined within exporters elsewhere, but I think it somewhat breaks nbconvert's architectural promises.

In addition to these user facing concerns it introduces some software dev issues. This PR overwrites a function inside this exporter that is only used (in first party code) by this exporter. That means that now we have to maintain two different pieces of code that now have different functionality, but the same name and are used to (ostensibly) accomplish the same things. To the extent that we think that markdown2html is used by 3rd party developers, I agree that it's important to keep that there for API stability. However, to the same extent the previous problem of people not being able to access the actual functionality we "intend" when we use our html exporter's version of markdown2html.

I understand why this is the kind approach that "needs" to be pursued in order to be able to apply the configuration here (given that filters are functions and therefore can't easily inherit configuration values from their parents). But that's exactly why making filters themselves configurable in the vein of #520 (i.e., without breaking any APIs) seems like (to me at least) the way to go.

[takluyver]

I don't think there's anything wrong with an exporter redefining a generic filter to do something more specific (in this case, using a config option on the exporter).

we have to maintain two different pieces of code that now have different functionality

Not really, to my mind. The new one is a trivial wrapper around the old one. Having configurable filters seems like more maintenance burden.

[mpacer]

I'm just going to merge this and close the other.