Fix: TextRenerer.paragraph is not a function

[FlorianKoerner]

Description

The method paragraph is missing in the TextRenderer.

Result

TypeError: this.renderer.paragraph is not a function

What was attempted

marked('Test', {
    renderer: new marked.TextRenderer()
})

Contributor

• Test(s) exist to ensure functionality and minimize regression (if no tests added, list tests covering this PR); or,
• no tests required for this PR.
• If submitting new feature, it has been documented in the appropriate places.

Committer

In most cases, this should be a different person than the contributor.

• Draft GitHub release notes have been updated.
• CI is green (no forced merge required).
• Merge PR

[UziTech]

I'm not sure that is the way it is supposed to be done.

Line 951 has a comment that reads:

// no need for block level renderers

@Feder1co5oave is there a reason block level renderers are not needed in TextRenderer?

[Feder1co5oave]

For now, TextRenderer is only used to strip markdown formatting out of headings' text, in order to generate a clean ID. They contain only inline formatting. See #450.

The same thing should be done for images' alt text, according to commonmark. See 2e23540.

It was not meant to be used as a renderer to parse a whole document, although it could be made into one by implementing all block level renderers consistently. That way it could be used to turn markdown code into plain text. Implementing only the paragraph one is not enough.

[UziTech]

@FlorianKoerner what was the purpose of setting the TextRenderer as the Renderer in marked?

[FlorianKoerner]

Originally my intention was to parse only inline blocks. Meanwhile I know that the TextRenderer is the wrong tool for this.

Is there an easy way to render only inline blocks?

[joshbruce]

See lines 856 to 858:

Renderer.prototype.paragraph = function(text) {
  return '<p>' + text + '</p>\n';
};

Is this what you were trying to access @FlorianKoerner and received a bad function call reference??

[joshbruce]

Not that I can tell given the way the renderer is described at the moment. Having said that, it might make sense in the future. We have inline and block flavors of the lexer and parser...and almost the renderer.

[joshbruce]

Tagging with #746 something to potentially introduce in 1.x or 2.x