Thanks for the detailed report, and sorry about the trouble. I was able to reproduce this with Bear 3.0 (14827), and it turned out to be a combination of issues on my end, not Bear's.
When Bear sends a note to Marked's Streaming Preview, it embeds any images directly in the text as base64 data. For notes with images, that makes the text very large. Two things went wrong in Marked:
- Every time Bear triggered the preview, Marked reset an already-open Streaming Preview window back to its placeholder text. Marked then ignored the note when it arrived again because it looked like a duplicate, which is why the content never showed up.
- Marked compares each update with the previous one to highlight what changed. Comparing a short text with a huge one (like the placeholder vs. a note full of images) used an enormous amount of memory, and it could happen several times per update. That's where the runaway memory came from.
On top of that, the Apex processor was corrupting the embedded image data (base64 contains "+" characters, and Apex was treating "++" pairs as insert markup), so even when the note displayed, the images didn't.
I've fixed all three, and the fixes will be in the next Marked update. With the fixed build, previewing image-heavy Bear notes stays at normal memory use, and the images render.
Until the update is out, a couple of workarounds:
- For notes with images, export the note from Bear (File > Export Notes, as Markdown or TextBundle) and open the exported file in Marked instead of using the Preview in Marked command.
- If you do use Streaming Preview, close the Streaming Preview window before previewing a different note, and force quit Marked if memory starts climbing.
I'll post here when the update is available. Thanks again for reporting it, and for the clear details that made it easy to track down.
