[Custom rules]: Consolidating issues and PRs

[joshbruce]

The community has generated interest in allowing Marked users to define their own rules.

[Feder1co5oave]

Following.

[joshbruce]

Changing to 0.5.0 based on conversations in other PRs and Issues. If we implement the ability to create custom rules - something like "target blank" becomes a potentially more elegant solution for a specific use case without muddying up Marked and working to cross-purposes against the supported specs. imho ??

[joshbruce]

Tagging in @ocdtrekkie and @drmuey for situational awareness.

[ocdtrekkie]

I am not super religious about implementation. Having a whole custom rules setup is arguably going to be a lot more code (I'd argue three lines of code to add a frequently-needed function is a lot more "elegant"), but a custom rules feature is also going to support a lot of additional use cases and less common functionality that wouldn't make as much sense to write a specific option for.

[joshbruce]

That's a fair point. I'm a pretty big fan of what I would call the big seven. DRY, YAGNI, and SOLID. (We would also need to seriously consider what constitutes "frequently-needed". Those three lines - multiplied by every "frequently-needed" function - can get pretty big pretty quick.)

The two principles I think leaning me toward this as a possible solution to the question of making marked do something other than straight adherance to various specs are the single responsibility and the open/closed principles.

Marked, if it has a single responsibility is captured well in the README:

The point of marked was to create a markdown compiler where it was possible to frequently parse huge chunks of markdown without having to worry about caching the compiled output somehow...or blocking for an unnecessarily long time.

The open/closed comes into play with the ability for users to access and extend the parser, lexer, and so on without actually having to modify the Marked core; thereby allowing Marked to maintain its single responsibility.