Add option to as_html for disabling HTML character escaping

[paradox460]

Adds an escape option, used by the HTML transform, to allow passing through of HTML tags without escaping.

Mostly useful when using table syntax, as there's no way to do newlines in a table cell without using <br/>

[RobertDober]

ty for your PR @paradox460
looking good but I'll need a little bit more time before I am merging

are you expecting a release or are you using your fork?

[RobertDober]

I am completely emberassed to ask you this, but I just cannot find the line where escape: false makes the difference, which, obviously it does, thanx to your test.

Seems I am blind after a tough week, so please bear with me...

[paradox460]

No rush for a release, if we need to we can point our mix at the branch until an update is released.

The affected lines are 179-188 of transform.ex. The actual sanitization functions (in the for loop) will only run if true, otherwise pattern matching will fall down to a pass-through of the function heads below that.

There's no explicit lines where escape: false makes a difference, rather, there are lines where escape: true (the default) makes a difference.

[paradox460]

Just thought up an edge case I missed, and fixed it. Now it behaves entirely as it should

[RobertDober]

Ty for your explanation, BTW I still do not see it, I'll just go through the code after merging 😊, you shalt not be bothered anymore 😉

[paradox460]

No problem, it took me about half an hour of probing to understand how the fall through worked.

Pattern matching is a pathway to many abilities some consider unnatural 🤣

[RobertDober]

Well spoken my friend, however as I needed some time to grasp it I wanted to take advantage of having myself familiarised with the code again and just released 1.4.14, (on 2021-02-21 what a nice symmetry) containing your nice addendum.

Thank you and keep safe.

If I were stupid and mean I'd say, it's Dave's fault ;)

Well but I am not mean 😏

[paradox460]

Looking over the recent additions, the post-processor looks like it will be extremely useful.

One thing that I've noticed is that many other parsers are highly extensible, i.e. Sundown, Redcarpet, etc. If you need help/input building an extensible interface for the AST parsing and such, I'd be happy to contribute what time I can. I can see that there are some requests for it, and it would be nice to add support for features from projects such as pandoc, kramdown, etc.

[RobertDober]

Thank you for your interest, what you are talking about would probably go into EarmarkParser but we can talk about here as well:

My priorities for EarmarkParser are quite set out:

1. Support ex_doc and this comes waaaay first.
2. Fix ongoing issues especially some request concerning HTML:
   • Allow reparsing inside HTML
   • Provide the parsed HTML verbosly in the meta hash
   • Parse HTML better (and remove the one tag per line restriction)
3. Better GFM compatibility (list parsing is way off)
4. New ideas

Unfortunately your ideas go into 4.

That said I would welcome help by all means, I have not much time and energy left right now. This also explains my conservative approach ex_doc is my raison d'être (I believe you borrowed that expression from us 😉)

Looking forward hearing from you