In my markdown file I have included prism js and css files that I downloaded from Prism website. I have specifically included the “Normalize Whitespace” plugin.
If I don’t have any white spaces in the code block, everything works fine, like this:
<pre class="language-python line-numbers"><code>df_employees.loc['478'] # returns series
df_employees.loc[['478']] # returns dataframe</code></pre>
And it’s properly rendered in the final markdown like this:
But if I add an empty space in the code block
<pre class="language-python line-numbers"><code>df_employees.loc['478'] # returns series
df_employees.loc[['478']] # returns dataframe</code></pre>
then the text gets messed up unpredictably. It can be like this:
or like this in the issue I raised in their repo on github
Is there anything I can do to troubleshoot the issue, since having empty spaces in the code blocks would be really helpfull for me.
If I understand you correctly, you’re not using markdown but HTML pre elements (in your markdown) to render code.
Which means that your question is not related to markdown nor to DT. It is about the role and behavior of the pre elements in HTML.
In your case, instead of showing screenshots of the HTML, you might want to look at it in the developer tools of your browser.
As the other person noted on Github, something is off in your example. But nobody can figure out what without more context.
There’s at least a part of a browser involved, you just do not see it: it is the built-in Webview of DT. Convert your MD to HTML in DT and open that in a browser.
Then you can use the developer tools to see
what the generated HTML looks like
which styles from which style sheets determine the look of it
And, seriously: I would not take the detour of MD if I only wanted to use HTML. MD can not do everything that HTML can, but displaying code blocks it certainly can. Just put them in three backticks
```python (or whatever language your code is written in)
code goes here
```
Mixing MD and HTML unneccessarily is adding more complexity.
Here is the complete Source view of the markdown file:
<link href="/Assets/prism.css" rel="stylesheet">
<script src="/Assets/prism.js"></script>
<link href="/Assets/prismCustom.css" rel="stylesheet">
<pre><code class="language-sql line-numbers">
SELECT * FROM customers
LEFT JOIN
orders ON customers.id = orders.customer_id
</code></pre>
The first two prism files are downloaded directly from prism web site (syntax highlighting, line-numbers plugin, etc), the third one is just my custom CSS with styling i like (kind of my own Dark theme).
You mean that since in MMD a return character designates a paragraph break, that’s the reason the P tags get injected into the HTML file whenever there is a return character?
That does make sense, but I wonder if there is way around it - I mean using MD and Prism in DT the way I would like?
It all depends on the Markdown parser used by DT. I have a hunch that it might be Multimarkdown 6, and if that one decides to add p elements like you see here – well, that’s that. You could use a <br> instead of a newline, though – that works.
On the other hand, I’d vote for using fenced code blocks instead, because they are easier to read and recognize and require less markup, so less risk of error. It would be possible to use line numbers in this case with one of the following methods
manually (ok, just kidding)
use a tiny JavaScript that takes care of it. It is actually trivial to insert into the MD document, but unfortunately it does not work right now due to a bug in DT’s handling of user-defined JS scripts. What you can do however, is to add the script to the source code of every MD file where you need it like so <script>document.addEventListener('DOMContentLoaded', () => { const code = document.getElementsByTagName('code'); for (let c of code) { c.classList.add('line-numbers') } });</script>
make the MD processor pick up more than just the language string following the code fence, something like ```language-sql line-numbers or ```language-sql {line-numbers} or whatever – there are tons of suggestions out there.
The last point illustrates the main problem: There is nothing like MD proper. There are a ton of dialects now, and one would have to decide which one to choose. Apparently, DT went with Multi Markdown, which is as underspecified as any of the other dialects. To put it more diplomatic: There does not seem to be a formal grammar for any of the current MD dialects that would allow users to figure out how they behave in which circumstances.
