I suspect there’s just way too much text in one note. Indeed, an experiment suggests so. Looking art the source (note: I’m afraid I can’t understand Cyrillic text) I noticed rulers which likely delimit different source notes. So, I took the source and copied it into BBEdit and replaced every instance of a ruler (of whatever length_ with 5 Euro symbols. So, before:
Now, I exploded the note on the
€€€€€ opting to remove the delimiter, giving me 15 notes. For these I applied the Markdown prototype. Now I select the first note:
…and choose ‘Preview’ in the text pane:
Now the page previews. But, moving down we find the preview chokes on the 10th note. At which point I think Tinderbox’s pipeline to Markdown rendering fails unrecoverable, as without an app restart, the preview now simple shows the last ‘good’ preview—which I suspect is simply cached data. as you note, trying to close/restart the doc & app only results in a cache.
I’ll ping @eastgate here as I can’t see far enough under the hood (I’m a fellow user) to see why this might be failing. I did paste the original example into MultiMarkdown Composer and the whole (big) page renders. So it looks like a gremlin in the source is breaking Tinderbox’s Markdown rendering. Why, I’ve no idea, sadly!
Side note: this is a massive note $Text. Tinderbox was originally designed around small notes. With something this size, I’d normally store the original outside Tinderbox, import the content, explode it into more manageable-sized notes and then delete the import.
So, my approach of exploded didn’t solve the problem but zero-ed in on a possible cause of the problem. I left in the information to help explain my thinking leading to the analysis above. Here is my v8.9.2 file with the original note, the same content, with delimiter substituted in BBEdit, and then exploded: … ah , TBX is too big to upload to the forum but the steps above should enable anyone to re-create the file.