Filters.

[lukasoppermann]

@michelf what do you think about adding a "filter" system?

With this one could add filters after the code is processed or before. It would make it easier to incorporate changes to the parsing because one could define filters when initialising the class.

Also instead of having to load a different class (namely the extras) one could just "activate" options by loading them.

Did you consider this? Is there a reason that you didn't do it like this or did it just grow to be more closely coupled?

[michelf]

It already works like that internally. Look at the constructor of the Markdown Extra parser, it just adds additional filters to the default ones defined in the plain Markdown parser. But I'm keeping this as an internal detail (which you can tinker with if you subclass the parser).

The problem with making things too pluggable is that it becomes untestable. With each configuration option, the number of possible combinations grows exponentially and unforeseen interactions become more likely. To tell the truth, the nasty side effects of the current system are rather telling that I should move away from this multiple layered filter approach and integrate the various features more throughly, like I did for the parseSpan function.

That said, I recently added a URL filter, and I would like to add output filters too (so you can tweak the output HTML). But tweaking the parsing without breaking other things is quite hard, I can tell from experience.

[lukasoppermann]

Ahh, okay, I see, I will look into it.

I believe you that it makes things more untestable, but if you have filters that are not interdependable, wouldn't it be enough to just test them in isolation?

Lets say you have filter to turn - [ ] into a checkbox, is there a need to test it in combination with an image filter for e.g.? What are the problems you are running into that make you saying that you should integrate features more tightly couple?

[michelf]

Well, you want - [ ] to turn into a checkbox, but probably not in all contexts. Not in an HTML block, not in a code block. What about lists of mixed checkbox/non-checkbox list items? And what happens if a <div> tag is hiding in the text beside the checkbox?

What needs to be taken care of will actually depend on the implementation details of your new syntax, this is just some ideas of things to check.

If you want this to work like the Github flavor, you probably should mix new code directly into the list-handling code to make things simpler. Or you could run a filter on the HTML output to replace any instance of <li>[ ] with a checkbox.

[lukasoppermann]

Hey @michelf I am actually not wanting this behaviour, I am just trying to understand where the pitfalls of a filtered system are so that I can try to avoid it / don't do stuff that creates problems, which you already know. :)

If I understand you correctly, you are saying, adding functionality via some kind of filter/plugin makes stuff more complicated to test than just adding it into the core. I just don't understand why. Or did I misunderstand you altogether?