RESOLVED Markdown editing slow in WYSIWYG mode

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?

Yes, sure:

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?

Disabling the automatic Wiki Links has no effect, unfortunately :frowning:

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/” (⟵ 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!!! :hear_no_evil::pray: Now, scrolling and editing Markdown files is so smooth, just as if I would scroll through a plain text in textedit! :heart::heart::heart::blush:

I apologize for any inconvenience and confusion I’ve potentially caused…the mistake was definitely on my machine :see_no_evil: 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!


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/”

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.


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/ (adding an extra t a the end)


And what is ls doing in that command?

Just had the same thought @chrillek - just updated my comment.