this post was submitted on 05 Jun 2025
92 points (97.9% liked)
Open Source
38107 readers
151 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Thanks for sharing, looks really cool! Especially with how prevalent markdown is.
Hopefully this isn't too off topic/thread derailing:
As a longtime LaTeX enjoyer, lately I've become increasingly infatuated by Typst. With Excalidraw quickly winning my favour as well ...
However I find myself daydreaming of some of Obsidian's powerfull features for knowledge graphing/"second brain"-ing, but given various reasons, never successfully convinced myself to use it. (Primarily: markdown seemingly a bit too simplistic for my preference, and Obsidian, to my knowledge, not being open source(?))
Instead I've tried some alternatives, each with excellent ideas, unfortunately none really hitting home with my wierd brain.
e.g. Zim, LogSeq, SiYuan, ...As such I'm curious to hear about others' setup, and thoughts. - Is Some(Quarkdown + Obsidian) perhaps what I've truly been longing for for?
As a Typst enjoyer I have to say this isn’t it imo from a quick look at the readme. Typst’s mix of markup and code modes is excellently designed and a high bar for anything to beat, and this looks like it doesn’t come remotely close. (I do have to say, I also heavily dislike Markdown in general)
Looking through some of the docs I'm afraid I won't be able to move off of Typst to this either. Typst has a long standing bug that I would have liked to avoid (lists that are too long will overflow memory and the maintainers seem to not want to temporarily dump to disk) but if even rust has an issue with those 100k+ row lists, I'm not sure kotlin will handle it better.
Lists with 100k items? Impressive. I can see how with a document like that it will run out of memory. Is it a stack overflow? You could try increasing the stack size in that case.