Next Version of Markdown Field

[fabianmichael]

Hey fans of Markdown,

I’ve been working on the next iteration of The Markdown Field plugin over the last months. It will be based on CodeMirror 6 instead of CodeMirror 5. Why is this great news? CM6 has much improved support for touch devices, such as the iPad and features and should resolve (most of) the performance issues, which have been present in version 1.

Although we now have great WYSIWYG capabilities built into Kirby, I still use Markdown/Kirbytext quite a lot, when it comes to technical documentation, knowledge management and blogging. I.e. everywhere, where dealing with large amounts of text, lots of links is more important, than having a sophisticated layout with lots of complicated blocks. The cool thing is, that the new version also comes with an enhanced Markdown block for Kirby’s blocks field, so you can mix the best of both worlds. And even cooler, the new plugin allows you to extend the syntax highlighting and even define your own dialogs for your custom toolbar buttons.

The current state (late alpha/early beta) can be found at: GitHub - sylvainjule/kirby-markdown-field at next

The reason for this early announcement is, that I ran into a few edge cases with nested formats, when toggling overlapping inline formats, such as bold (**bold**) and italic (*italic*) texts. In these cases, Parsedown (Kirby’s Markdown Parser) fails to recognize these correctly, but the editor’s parser interprets them correctly. Example:

wo*rd **wo*****rd word**
should become:
wo<em>rd <strong>wo</strong></em><strong>rd word</strong>

But Parsedown is able to handle it correctly, when using the underscore _ character for italic text instead:

wo_rd **wo**_**rd word** (works fine)

I now have to make a decision, whether the editor will use the asterisk * for marking italic text or if it will use *. I personally tend to use the asterisks for both bold and italic text, but Markdown theoretically supports both. This is truly an edge-case, but I still need to make a decision now. The editor has to settle on one character for marking up italic text, when you press the “I”-Button or hit the corresponding keyboard shortcut.

Please answer the poll and feel free to leave some early feedback in this thread.

Which syntax do you prefer?

• *italic*
• _italic_
• Don’t care

[francoisgm]

Hello,

Well there was an issue I kept bumping using the Markdown Field plugin: if I would have to add a link with the target: _blank attribute then it would cause the content after to be previewed in italics although it is not, which is slightly annoying.

Would using _italics_ make situations in which one uses a target: _blank problematic or that has been taken into account?

I use the Markdown Field for almost every project and I’d be eager to see its next iteration. Thanks!

[fabianmichael]

Can you give me some example input? CodeMirror 6 has a new parser, that deals a bit better with that. So only _italic_ would cause something to be highlighted. But Kirbytags-Highlighting – unfortunately – cannot happen on parser-level without investing much more work. So it is still possible to fool the parser, but it should still be much more reliable.

[francoisgm]

That was an issue I bumped on Sylvain Julé’s iteration and haven’t tested your beta version: if the current parser you’re using is harder to fool then that’s great news. I should check out.

[fabianmichael]

Okay, it seems that _italic has won. If will proceed with that syntax from now on, when you hit the toolbar button or the keyboard shortcut. Thanks for all of your feedback.

[AudioBear]

Hi Fabian, so what happens when we have lots of text in Markdown fields and we re-save or edit? I presume it translates *italic* to _italic_ ? I’m not sure how practical it can be for us having trained authors to use *italic*. Or indeed how it will work with 85 books online with many, many pages and these being converted to epubs…

I know it only seems like a small change, but I’m struggling with the implications but of course understand why you are doing it. It is a great plugin, but perhaps an option to use one format or the other?

I note some questions about URL above, how would it cope with a common style wiki commons entry like:
https://commons.wikimedia.org/wiki/File:Kersting_-_Paar_am_Fenster.jpg

[fabianmichael]

@AudioBear

Hi Fabian, so what happens when we have lots of text in Markdown fields and we re-save or edit? I presume it translates *italic* to _italic_ ? I’m not sure how practical it can be for us having trained authors to use *italic* . Or indeed how it will work with 85 books online with many, many pages and these being converted to epubs…

I know it only seems like a small change, but I’m struggling with the implications but of course understand why you are doing it. It is a great plugin, but perhaps an option to use one format or the other?

I had discussions with other people and will add an option, so you can choose which characters the editor will use, if you hit the “Bold” or “Italics” buttons (or keyboard shortcuts). It seems, there’s no way around it and I don’t want to force my personal preference onto anyone. The Markdown parser and highlighter will – of course – continue, to support both _italic_ and *italic*.

---

Unfortunately, the highlighting of KirbyTags has to happen after the Markdown parser has finished. The Markdown parser works according to the CommonMark-Spec and makes a clear distinction between block and inline elements, which collides with the logic of KirbyTags. E.g. in Markdown, a strong emphasis cannot span across line breaks, but Kirbytags can contain line breaks and their HTML output can even split paragraphs.

However, the new parser is much harder to fool and should only screw-up in edge cases.

This works:

This does not work:

[AudioBear]

Thanks for taking the time to explain fabianmichael. I understand the difficulties and appreciate the trickiness of the problem. I agree that letting the user choose their options and accept any limitations that this might mean is probably the best way forward. I’m also more than a little relived that I don’t have to persuade users that _another way_, is the way forward!

Much appreciated!

[fabianmichael]

@AudioBear @francoisgm After testing out the implementation explained above, I noticed that moving the Kirbytag parser to language level by extending the Markdown parser makes more sense. It will probably be a more common scenario to have an underscore within a Kirbytag, than having multi-line Kirbytags. Bonus: Using a single line-break won’t break most markdown elements, and thus won’t break Kirbytags either.

In the latest beta of the plugin, the editor won’t get confused by having sth. like (link: … target: _blank) and_more any longer!

[AudioBear]

Hi @fabianmichael, that indeed does sound like a great way forward. I’m a bit snowed under at the moment but will try and test the beta as soon as I can.