Respect for building the client from scratch. The "I wanted to understand every component" reasoning resonates. I took a similar approach with a conversion pipeline I built using remark/rehype directly rather than wrapping an existing markdown-to-HTML library. You end up understanding every edge case which matters when you need to handle things like nested tables or math rendering.
3.5 years solo is serious commitment. What was the hardest part ... the real-time sync or getting the editor to feel right?
Tables are markdown's weakest point. The pipe syntax is painful to write and impossible to maintain once a cell has more than a few words. An excel style approach makes a lot of sense for that.
One thing I've found tricky is the round-trip: editing a table visually and converting it back to clean markdown without the alignment breaking. How are you handling that ... regenerating the pipes and padding on every edit or storing some intermediate state?
Nice approach keeping it minimal. Tufte CSS is a solid choice for readability. Interesting that you went with BibTeX citations in markdown. How are you parsing those? custom remark plugin or something else? I've found the remark/rehype ecosystem handles most markdown extensions well but citations tend to need custom work.
Nice to see a native viewer. The electron fatigue is real. I've developed several apps on Electron and have moved away from it.
Curious about the rendering pipeline ... are you using a Swift markdown parser or wrapping something like cmark/commonmark under the hood? The tricky part I've found with GFM rendering is getting tables and task lists to behave consistently, especially when you add LaTeX and Mermaid on top.
3.5 years solo is serious commitment. What was the hardest part ... the real-time sync or getting the editor to feel right?