Thank you for the screencast! Could you please post screenshots of Preferences > Editing, Preferences > WikiLinks and Preferences > Files > Markdown too so that we could reproduce the same setup?
One more screenshot of Preferences > Editing and I might be able to reproduce this, thanks. By the way, does disabling the automatic Wiki Links make a difference?
I found that disabling MathJAX support (Preferences ā Files ā Markdown ā Extensions) removed a lot of the lagginess in editing mode I was experiencing.
[Edit: I see you already disabled that.]
1 Like
Does this behavior generally occur or just on this document?
1 Like
It occurs for every longer textā¦but it canāt accurately determine, how long is a ālongerā text. The one of the example above is already very longā¦but the issue occurs also with texts of half of that length or even shorter, while the duration of the lag decreases with decreasing text length ā but only if the amount of the formatting decreases simultaneously. I.e., also half long or shorter texts can cause the lagging if they have a mid to high amount of formatting (headings, links, etc.). The weird thing is, that after a quick switch from edit to preview mode and then back to edit mode, the lag is gone ā as if some cache has been reset or so (at least until you reach another formatting cluster region).
Thanks. Iām not seeing it yet but Iāll try some more.
1 Like
[SOLVED]: The lagging was caused by the font server in my macOS Big Sur 11.4 installation.
This morning I noticed in the activity monitor app, that simultaneously when the lagging in a DT Markdown file occurred, the process āfontdā started to consume a lot of CPU power:
Switching from edit to preview mode causes that CPU usage to decrease again. After turning back to edit mode, the lagging was gone and I could smoothly scroll through the text until I reached a text region with a lot of formatting (as previously described) ā and then again, āfontdā consumed a lot of CPU power.
Killing that process (within the application monitor app, via terminal ārm -f ls ~/Library/Preferences/com.apple.FontRegistry.user.plistā (āµ use with care, see comments below!!), or by clearing the font cache) brought a little shorter lagging time, but the āfontdā process restarted immediately and consumed again a high amount of CPU power. Iāve then updated my Mac to macOS Monterey 12.3, and since then the āfontdā-high-usage-problem and also all lagging in DT was gone!!! 
Now, scrolling and editing Markdown files is so smooth, just as if I would scroll through a plain text in textedit! 
I apologize for any inconvenience and confusion Iāve potentially causedā¦the mistake was definitely on my machine 
I have no idea what caused the font server to show this behavior. I just noticed that the same large files, that I have edited e.g., in January 2022, have become ālaggyā now in March. I havenāt installed any new font, also a check-up in the font book app showed no error. Also, I havenāt updated my macOS within this time. I suspect a background update of another third-party app could have caused the corruption. I turned off automatic app updates just to be on the safe side from now on ^^
Thanks to everyone here! The support by the DT team and the community is just awesome!
2 Likes
Wonderful and no worries!
Itās definitely an outlier therefore hard to pin down what was causing it.
@et al and to passersbyā¦
via terminal ārm -f ls ~/Library/Preferences/com.apple.FontRegistry.user.plisā
Please donāt think of this as *prescriptive should you run into a similar issue; it is descriptive of the process followed by this person.
Use of the rm UNIX command, especially with the -f argument is potentially disastrous if entered incorrectly.
2 Likes
As an addition: if this is a solution you want to try (please read @BLUEFROGās comment carefully!) the correct command would be rm -f ~/Library/Preferences/com.apple.FontRegistry.user.plist (adding an extra t a the end)
2 Likes
And what is ls doing in that command?
Just had the same thought @chrillek - just updated my comment.