I believe I may have found a bug in the MultiMarkdown Syntax highlighter. I’m currently studying an intro level JS course and adding a whole bunch of code blocks in MultiMarkdown draft. As I add more and more, it seems like the on-screen rendering gets confused and starts showing everything below a certain portion as code env if the code block has been closed off. Usually this goes away by switching to a different Draft and then coming back but now it seems like it’s broken.
I can provide the .md file if desired (not allowed to attach here in the forum). Here’s a screenshot illustrating the problem.
To do syntax highlighting, you have to scan the text. To truly be correct in a longer document with a lot of code blocks like this, you have to rescan the entire text to find the paired sets of ticks. Unfortunately, that can be really slow to rescan the entire document for every change. This is less of problem with shorter documents, and less of a problem on Mac than on iOS, but to minimize the performance issues, the default syntax definition for MultiMarkdown is currently configured to look around a text change up to 1000 characters ahead and behind to evaluate syntax.
This means you can get in a case like you describe where you end up with mismatched block elements in the scope of the evaluation. If you reselect the draft from the list, the full text is evaluated, and the variance corrected.
This is configurable in Drafts syntax engine. Once custom syntaxes become available later this year, you could configure an alternate MMD syntax that always evaluated the full text. As it stands, I don’t think it’s a good default, because it longer documents it can create a real noticeable lag when typing.
As mentioned in my above response, you can do this with custom syntaxes, as long as the trade-off of performance is not an issue for you. Those were not available at the time I made that comment, but are now.
If you use code blocks a lot, and want to always force syntax highlighting to re-evaluate the entire content of the draft on each render pass, you can alter the syntax. Export the “MultiMarkdown” syntax, open it in a JSON editor, and change the rangeExtensionType default value to “fullText” instead of “lineExtended”, like:
Also, probably, change the name property to “MultiMarkdown-Custom” or something to more easily distinguish the syntax, import it into Drafts, and assign this syntax to your draft (or as a default for new drafts).
If you use that, it will not be susceptible to this issue. More on modifying syntaxes and this value:
I understand the point you are making and I’m sure you’ve considered this very carefully, but this design choice is really painful. I frequently use Drafts for code documentation and it is pretty much unusable. Is there anything that can be done to improve the usability for code blocks? How about adding an option to the preferences, so that I can at least toggle between rendering modes.