issues with es6 template strings

[jhicken]

Imagine a function like this...

function masterRunner(){
  var conv = new showdown.Converter()
  return conv.makeHtml(`
    ## markdown doc
    you can use markdown for card documentation
    - foo
    - bar
  `)
}

this is the output

<pre><code>## markdown doc
you can use markdown for card documentation
- foo
- bar
</code></pre>

It means i always have to untab my markdown.

I understand why but it seams ungood.

[tivie]

I see your point but this is hardly a showdown issue.
I can't think of any sane way showdown core can ignore tabs smartly without breaking the tab code blocks.

To further elaborate...

Tabs and spaces at the beginning of lines are meaningful in markdown syntax.
This makes it impossible for showdown to know for sure that, in your specific case, those "tabs" at the beginning are not intentional. Showdown might try to guess, let's say, if all lines of the text are indented the same way but this would break a perfectly valid case like this one:

var conv = new showdown.Converter();
conv.makeHtml(
`
    this is
    a multiline
    piece of code
`);

Also, the indentation at the beginning of lines is arbitrary, depending of your code style and how deep in the code is the markdown text. This makes it hard to implement at best....

@jhicken Do you have any suggestion?

[tivie]

To fix your specific issue, however, you have several options:

Move es6 template strings to a new line

You can fix the issue by moving the es6 opening mark to a new line that respects your indentation:

function masterRunner() {
  var conv = new showdown.Converter()
  return conv.makeHtml(
    `## markdown doc
     you can use markdown for card documentation
      - foo
      - bar`);
}

Use a wrapper function

you can also use a wrapper function, although I think is really an overkill and potentially breaks tab code blocks:

function masterRunner(){
  var conv = new showdown.Converter()
  return conv.makeHtml(t(`
    ## markdown doc
    you can use markdown for card documentation
    - foo
    - bar
  `));
}

function t(txt) {
  return txt.replace(/^\s+/gm, '');
}

Make the above t function a lang extension

This would remove the need to pre-parse the text but, again, I think is an overkill.

[jhicken]

Hey thanks for the response.

So If i use option 1 (Move es6 template strings to a new line)

This is what i get. The first line is converted and nothing else.

<h2 id="markdowndoc">markdown doc</h2>

<pre><code>  you can use markdown for card documentation
  - foo
  - bar
</code></pre>

the alternative is

function masterRunner() {
  var conv = new showdown.Converter()
  return conv.makeHtml(`
## markdown doc
you can use markdown for card documentation
- foo
- bar
  `);
}

Which is also not super great. (this is what im currently doing)

Using something like option 2 up above would work but would need some major testing to make sure you don't remove white space from unintended lines.

My proposal is that showdown could let you pass an argument that would try to intelligently fix your es6 string.

Is that crazy?

[tivie]

My proposal is that showdown could let you pass an argument that would try to intelligently fix your es6 string.

Yeah, but how would we accomplish that? Right trimming would not work as it would remove important right whitespaces.
Passing the indentation level would be kind of useless since it would tighly couple the text with the code style, which is crazy!!

The only way I can think of is guessing by the the "indentation" level of the first line of the text, but that would also break under some circumstances such as:

• first line of text not indented but the rest is
• a list or a code block as first element in a string
• etc...

So what did you have in mind to tackle the problem?

[tivie]

Check 261f127 and see if it fixes your problem,

Its on it's own branch since I would like further testing before introducing this feature on core.
This type of "smart" indentation fixing is problematic and I don't think we can create a system that reliably can identify indented text.

[tivie]

@jhicken Have you had time to check and test 261f127 ?

[jhicken]

I have not. Sorry been super busy. I'll try and get to it tonight. Ps thanks for working on this.