Skip to content

Add ability to specify custom Formatter for Pygments code highlighting #490

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

Closed
wants to merge 2 commits into from
Closed

Add ability to specify custom Formatter for Pygments code highlighting #490

wants to merge 2 commits into from

Conversation

dprothero
Copy link

In our use of the Python-Markdown library, we discovered the need to be able to use a custom Pygments Formatter class. Pygments supports creating custom formatters, but there wasn't a way to have the CodeHiliteExtension utlize them.

I've added pygments_formatter as a config option for the CodeHiliteExtension class (which is also used by FencedCodeExtension). It can take a string, which will be passed to the call to Pygments' get_formatter_by_name function. It defaults to 'html', which is what was hard-coded before.

Also, the option can take a reference to a class. This makes it convenient to specify a custom class in code without having to create a separate package for your custom formatter. Usage is something like this:

def get_html_from_markdown(value):
    # Use the extra extensions
    from code_samples.code_formatters import MarkdownHtmlFormatter
    return markdown.markdown(value, extensions=[
        'markdown.extensions.extra',
        TocExtension(anchorlink=True),
        CodeHiliteExtension(pygments_formatter=MarkdownHtmlFormatter)])

The last line of code demonstrates the usage.

All tests pass (aside from those marked as Skip), including the additional test I added. Let me know if you'd like any modifications.

@atbaker
Copy link

atbaker commented Aug 25, 2016

I work with @dprothero. As front end design evolves, I'm sure we're not the only ones who could benefit from specifying custom formatters.

Thanks for your maintenance of the project and for giving this PR a look!

@waylan
Copy link
Member

waylan commented Aug 26, 2016

Cool! I like it. And I would merge this if we weren't in a feature freeze right now. We are only accepting bug fixes at this time. As we move toward version 3.0 (see the roadmap) the extensions will be broken out into separate packages and will no longer be tied to the development/release cycle of the main package. At that time these sorts of things won't hold up a good contribution like this. Unfortunately, until then, this will have to wait. Of course, in the meantime, you are welcome to fork the extension as long as you honor the licence.

@waylan
Copy link
Member

waylan commented Aug 26, 2016

Oh, and before you ask, the timeline is "when it's done."

@dprothero
Copy link
Author

That sounds totally fine to me! We'll just keep my fork in our requirements.txt until this all comes together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants