pass parser options into convert

[ghepting]

When using the .to_kramdown converter, we were unable to pass the :raw_text option through to avoid escaping text such as {foo_bar} etc. This change passes all parser options through to the converter – not sure if we want that or another interface to pass the options through on .to_kramdown but this seemed okay with my basic testing. Looking for input/insight from maintainer to verify strategy here.

[gettalong]

I'm not quite sure what you want to achieve by passing the options of the converter back to the converter as an argument to one of its methods:

converter.convert(tree, converter.options)

Could you provide a full example that doesn't work as you would expect?

[ghepting]

Yeah I'll post reproduction scenario in the morning tomorrow absolutely

On Thu, Aug 25, 2022, 6:26 PM Thomas Leitner @.***> wrote:

I'm not quite sure what you want to achieve by passing the options of the converter back to the converter as an argument to one of its methods:

converter.convert(tree, converter.options)

Could you provide a full example that doesn't work as you would expect?

— Reply to this email directly, view it on GitHub https://github.com/gettalong/kramdown/pull/761#issuecomment-1227819367, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADYIHP5ZRVSMXP7IDJYAE3V27XH7ANCNFSM57US37FA . You are receiving this because you authored the thread.Message ID: @.***>

[ghepting]

Okay so here's the before/after

before:

after:

As you can see, I'm needing to get raw_text: true option passed all the way down to the converter.convert method in order to leverage the logic here: https://github.com/gettalong/kramdown/blob/master/lib/kramdown/converter/kramdown.rb#L77-L78 and not have this raw content get escaped. We're using some simple handlebars template tags within the plain text of our documents because it's only 1 phase of an ETL pipeline before some variables are injected for an email send.

Very open to input/education here if there's a better way to accomplish this that we've missed in our reverse engineering! :)

[gettalong]

There is no raw_text option in kramdown, so it seems you are using a custom option. However, what you really try to use is a converter specific and internal option of the kramdown converter that has nothing to do with the general option mechanism.

What you wanna do is create a custom kramdown converter that handles your text nodes specially, i.e. by always outputting them as is. This, however, might lead to problems parsing the result as kramdown without a pre-processing step (which you probably have).

[ghepting]

Ah, okay I'll just setup a custom converter that removes the escaped characters after the kramdown conversion so it's unobtrusive and a more clear additional processing step. Thanks for the time & guidance.

[gettalong]

No problem. I think it is a clearer solution than (ab)using some internal state and makes it clearer what you want to achieve. Feel free to contact me if you run into problems with the converter.