Always wrap CodeHilite code in tags by t-mart · Pull Request #862 · Python-Markdown/markdown (original) (raw)

do you prefer to squash on merge instead

I squash except for those rare occasions were a PR contains a perfect commit. With your force push, your commit was good. However, I still used squash so I could add a technical note to the commit message. In other words, as long as the final product is good, I'll happy squash it. GitHub makes that easy with their web interface.

I'd like to take some time to refactor it if you have the appetite for that.

This extension is over a decade old, so yeah, it needs some updating/refactoring which I have not had time to work on. Reviewing some of the open issues/PRs (#334, #775, #652, #822 and perhaps others) will provide some insight into the planned direction. Feel free to ask questions or propose solutions in the various discussions in those issues/PRs.

Note that the extension serves two functions:

  1. Provide a mechanism for defining the language of indented code blocks. This allows the user to add their own code-highlighting (perhaps via a JavaScript lib) separately. The idea is that we replicate the output and behavior of fenced code blocks for indented code blocks.
  2. Highlight the code within all recognized code blocks, including any alternative code blocks provided by extensions. Obviously, this includes fenced code blocks, but should be able to work with code blocks produced by other third party extensions as well.

Note that the extension always performs function 1. However, function 2 can be optionally turned off by the user. Any refactor must maintain this division of functions.

I'd also like to make Pygments a required package for Python-Markdown

As long as CodeHilite is included with Python-Markdown I am not comfortable with this. We are proud of the fact that Python-Markdown has no dependencies (except Setuptools). Many users of Python-Markdown never use or need CodeHilite. Others may use CodeHilite for function 1 (as described above) but never need Pygments. Therefore, we should not require all users of Python-Markdown to have Pygments installed.

We have contemplated breaking extensions out into separate packages. If that were to happen at some point in the future, then yes, requiring Pygments as a dependency would make sense. Until then, I'd prefer to leave the requirement as-is. At this time, we are not planning on breaking out the extensions.