And do you use a specific plain text font or the default one? See Preferences > Editing
1 Like
Yes, I’m using a specific plain text font: Helvetica (or Helvetica Neue - will check it when I’m back at my Mac)
I will set the plain text font back to default (later) just to ensure/check if this causes the error.
Do you still experience this after switching back to the default font? Press the Option modifier key in Preference > Editing to reset fonts.
1 Like
I reseted the plain text font to default (using the Option modifier key) and this had no effect. I also switched back and forth (from default (Menlo) to Helvetica to default), without an effect regarding the lagging-issue.
I turned the Wikilinks on and off as well as the WYSIWYG editing mode – also with no effect.
I forgot to mention (as I rarely do it): If I open the inspector or resize the window, which of course leads to a new text wrapping, the Markdown window (in edit mode) lags or gets even frozen – for a time depending on the amount of links and length of the text. If I repeat the same steps in preview mode, everything works fine.
I’m using Devonthink 3.8.2 on macOS Big Sur (M1 chip, MacBook Pro 2020).
Meanwhile I did some more tests. I now think that turning off the WYSIWYG editing mode indeed has an effect: All lagging vanishes while this mode is turned off (regardless whether the plain text font is set to the default font or sth else). Furthermore, the more formatting markup commands the Markdown text contains ("#, ##, …", “**bold**”, "*italics*, "_italics_, “==highlighting==”, “[link text](link)”, …), the slower the rendering (in edit mode) becomes. It seems, that the lagging issue does not only concern links, but any Markdown formatting (or their amount) while WYSIWYG is turned on.
Which version of macOS do you use? In addition, an example document would be great - thank you!
1 Like
Sorry for my delayed reply. I’m using Devonthink 3.8.2 on macOS Big Sur 11.4, M1 chip, MacBook Pro 2020.
In the meantime, I’ve created a screencast with a Wikipedia entry (Blackbirding – Wikipedia) as an example (I copied the entry w/o the images, but preserving all formatting and links):
It shows the lag in editing mode while reaching a text part with many formatting (here: the links) or the uppermost heading, while in preview mode everything runs smoothly as well as in editing mode with deactivated WYSIWYG. As mentioned above, changing the plain text font to its default does not affect the lagging. I tried to turn off all extensions (MathJAX, Mermaid, Prism), also without an effect.
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?