Enable --redcarpet-ext option to allow any RedCarpet extension(s) like tables one. refs #623

[akzhan]

Typical use is writing to .yardopts:

--redcarpet-ext tables

[lsegal]

Unless there's a way this could be done in a markup agnostic way, I don't think I would accept this patch. I don't like the idea of having extension specific flags cluttering up the options. We would have to do the same for rdiscount, redcloth, maruku, rdoc, etc.

Perhaps --markup-ext would be better.

Alternatively this could be implemented as a plugin.

[akzhan]

@lsegal Hear me:

• I need tables to complete the documentation suite.
• I doesn't know nothing about plugins. But your code seen as not pluggable in part of markup provider creation.
• Any option renaming doesn't matter for me.

[akzhan]

I can rename it to --markup-ext and pass it to other markdown providers, but it's false in the depth.

[akzhan]

And by the way, what's wrong to have --maruku-ext or something else?

We need specific options because Yard is used in specific environment, ANYWAY.

Usually RedCarpet one ;)

[lsegal]

@akzhan

I doesn't know nothing about plugins. But your code seen as not pluggable in part of markup provider creation.

Sure it is. Nothing is stopping you from alias chaining html_markup_markdown and checking for the provider name first, overriding the original behavior. The story for accepting command line arguments is a little more awkward, but you could certainly just grab the extensions to apply from environment variables. Worst case scenario is just hardcoding the extensions you want to be applied, and you could certainly use this for your own projects.

what's wrong to have --maruku-ext or something else?

Because this is an inconsistent story for users. It also means when someone types yard --help they will potentially be flooded with tons of options that they don't care about.

YARD is inherently designed to be abstracted away from implementation details such as the markup provider. All of the markup provider code is done in such a way to support multiple providers. Anything that supported extensions would have to be designed in the same abstracted way.

I would accept a patch that was abstracted an accepted extensions that could be passed into ANY markup provider (with tests). Also keep in mind to ensure that your tests pass before submitting pull requests. Travis shows that your code has failing tests, so you should make sure everything works.

[akzhan]

Ok, boss.

I just pushed https://github.com/regru/yard-redcarpet-ext-plugin and it does I need.