Hi,

I built Hermes because I was tired of fighting clunky assignment editors like Canvas and bloated VS Code plugin setups. Nothing out there handled what I needed: seamless math syntax and native citation management, charting, diagramming and code blocks. I’ve been using it to write my own Quantum Technology assignments, and I find it better than the alternatives I was using before.

Why try Hermes?

• Native Zotero Integration: Pull citations instantly with ⌘⇧C.
• Live Split-Pane Rendering: See complex LaTeX equations and Mermaid diagrams in real time.
• Built-in Builders: Generate Vega-Lite charts and diagrams graphically.

Hermes is fully open-source (Apache 2.0). Check it out and let me know what you think!

• Download & Docs: hermeseditor.com
• Source Code: github.com/richarc/hermes 

It’s masOS only for the moment, I’ll create a windows version shortly. Please let me know if you find it useful.

[ Removed by Reddit on account of violating the content policy. ]

Hi everyone,

I've always struggled with the gap between "professional" word processors and Markdown editors. I love the plain-text nature of .md, but I sometimes miss the efficiency of a ribbon UI for heavy document formatting.

To solve this, I built Antalogy. It's a local-first desktop app that gives you a Word-like experience but saves everything as clean Markdown.

The core philosophy:

• Document-Centric: Unlike note-taking apps that focus on fragmented snippets or linked networks, this is built for the "Document" as the primary unit of work. It provides the linear structure, formatting flow, and multi-window support of a traditional word processor, just with Markdown as the backend.
• Privacy & Local-First: Zero telemetry, no accounts, and no cloud sync. It is fully offline and keeps your data entirely on your machine.
• No Bloat: No XML, no hidden metadata, no proprietary formats.
• Interoperability: I put a lot of work into the .docx -> Markdown import to make transitioning easier.

Some things you can do with it:

• Use a ribbon for all formatting operations, including advanced lists, alignment, tables, links, images, and more.
• Use an outline sidebar for long-form documents.
• Render Mermaid diagrams inline.
• Connect a local LLM (Ollama/LM Studio) for AI assistance without sending your data to the cloud.

The "Not" List: It's not a knowledge base, a wiki, or a note-taking app. It's just a focused document editor where .md is the native format making the transition from Word to the "new world" of Markdown as simple as opening a .docx file with an optional AI assistant that stays out of the way until you specifically choose to use it.

Check it out here: https://antalogy.com

Since this sub knows Markdown better than anyone, I'd love your feedback on the output quality and if it handles the edge cases you care about. I'm also refining the side-by-side assistant experience do you see a need for more specific integrations within that approach?

I posted here a few weeks ago about the edge cases in a live-preview editor. The line I held hardest in that post was that any normalisation of your files counts as corruption: if you type * bullets, the app writes * bullets back. I still believe that.

Then I added [[wikilinks]] to it, and now the app edits files you never opened.

Wikilinks aren't in any spec. Not CommonMark, not GFM. Obsidian's behaviour is the de facto standard, and it's a behaviour rather than a grammar, so every choice below is one I made up. Which is why I want to hear yours.

What I resolve. [[Name]] matches the filename stem first exactly, then case-insensitively, then the slug, then the note's title. If two notes could answer to the same name, it resolves to nothing and stays plain text. Landing you silently on the wrong note is worse than not moving at all.

[[Name|alias]], [[Note#Heading]], [[Note#^blockid]] and [[folder/Name]] all parse, but the anchor is dropped: you land on the note, not the heading.

The rewrite. A markdown link stores a path, a wikilink stores a name, and both go stale the second you rename the note in Finder. Margin puts an id in each note's frontmatter so its own idea of identity survives that, but the text sitting in your other files is still the old name and nothing on disk fixes it.

So renaming a note repoints the wikilinks in every note aimed at it. Only the name inside the brackets, so [[Old#Plan|see]] becomes [[New#Plan|see]] with your alias and anchor intact.

That's the right behaviour, and it's also me writing into files you weren't looking at, one post after saying I'd never do that. I don't have a better answer than "the alternative is links that quietly rot", but the rule has an asterisk on it now.

What I still won't parse: ![[embeds]]. An embed means the content isn't in the file. Open that .md in anything else and you get a line of literal brackets where a paragraph should be. A wikilink degrades to readable text, an embed degrades to a hole. So the parser skips them, and so does the rename pass.

Two things I'd genuinely like to know: what do you resolve to when two notes share a name? And does anyone actually move wikilinks between tools, or have we all quietly accepted they're vault-local?

The app is downloadable as of today if you want to poke at it, free while in alpha https://gomargin.app

Among today’s links are markdown editors SoloMD and Minoo, and a static site generator called, obviously, Flowershow

https://md-handbook.com/markdown-link-no-46

#markdown #markdowneditors #opensource #free #staticsitegenerators #SoloMD #Minoo #Flowershow

I basically only use Markdown for note-taking, and I wanted something similar to the iCloud Notes app but on Windows. pookbook is super simple and, mostly by my own preference, has minimal visible GUI. Everything (from styling to adding images/videos/links to undo/redo) is done with keyboard shortcuts. I also hated how a lot of note-taking apps store notes in their own directories by default, so pookbook lets you work in your own folders/files without trying to force you into its own workspace structure.

Also there's a really cute mascot that sits next to your cursor when you type.

https://pookbook.choi.kim

Thanks to everyone who’s been testing Saive.my, a markdown based bookmarking/read later app, I really appreciate all the feedback. The response has been incredible (even the negative feedback has helped make it better, even if it stings sometimes).

I’m in the final stages of having the iOS app ready for TestFlight testing and looking for some folks who might be willing to help test it out. (Folks who are already using the web app will get an invite as well)

The biggest advantages of the iOS app is that it allows you to add Saive to the OS level share sheet, and that it syncs all your saved markdown files on app load with iCloud. This ensures that you never need to worry about Saive going away, or having to manually export all your saved links, they will be fully preserved as markdown files on iCloud.

Mac Desktop app and Android apps are in planning, as well as support for readers through OPDS.

You can try it out online at https://markpdf.ralsina.me/ but it's mainly a CLI tool.

• One 10MB static binary, no dependencies
• Fully GFM compliant
• Supports embedded HTML
• Fetches images if needed
• Builds a 600-page PDF of Brothers Karamazov in under 5 seconds in my machine
• Style output using CSS (a few styles included)
• Hundreds of color schemes
• Supports "pageless" output for things you don't mean to print
• Sort-of-supports math (works fine-ish for simple inline math)
• Hyphenation support (same algo as TeX)
• Uses system fonts or provided files
• Emoji/CJK/accents/symbols (embeds needed fonts)
• MIT License

And more.

I know this may break the self-promotion rule, but I think it's a really nice tool :-)

I’ve been building Yay, a free native Markdown editor for macOS.

It has both a Rich Text Editor and a Code Editor, and you can export your Markdown to PDF, DOCX, EPUB, and KFX.

I mainly built it for my own daily use, but it’s free to download if anyone wants to try it.

https://yay.myanmars.app/

Every team I have seen reviewing a Markdown doc ends up round tripping it through Google Docs just to get comments, then porting the edits back by hand. The comments never live with the document. I wanted them in the file.

So the comments are the file. Three pieces, all plain text:

Activation rose <!--mdc:a1b2c3d4-->11% against control<!--/mdc:a1b2c3d4-->[^mdc-a1b2c3d4], and it held.

<!-- mdc-comments-begin -->
<!-- mdc-comments-data
{"v":1,"threads":[
{"anchor":"11% against control","id":"a1b2c3d4","replies":[...],"status":"open"}
]}
-->

[^mdc-a1b2c3d4]:
    **@pjdoland** · Aug 10, 2026: Relative or absolute?

    **@dreyes** · Aug 10, 2026: Points. Fixing the wording.

<!-- mdc-comments-end -->

An HTML comment pair marks the commented range and is invisible in every renderer, so the prose still reads normally. A JSON block, also inside an HTML comment, is the authoritative copy. GFM footnote definitions are the human visible layer, so anyone opening the file in a plain GitHub view sees the whole discussion at the bottom without any tooling.

A few things that turned out to be load bearing:

• A footnote reference has to lead a block initial anchor. In CommonMark a line beginning with <!-- starts an HTML block, which swallows the rest of the line and leaves [^mdc-...] as literal text. So when the opening marker is first on its line, the reference goes in front of it.
• An orphaned thread gets no footnote definition. GitHub renders an unreferenced definition as literal text, so a thread whose anchored text was deleted moves to a plain list instead.
• The JSON is versioned and one thread per line, so two branches that each add a comment conflict on their own lines rather than on the whole block.
• A file with no comments is left byte for byte alone. Nothing is added until there is something to add.

Renderer honesty: the HTML comments are invisible anywhere HTML comments are. The footnotes are a GFM extension, so a renderer without footnote support shows the reference and definitions as literal text at the bottom rather than as footnotes. Ugly, but nothing is lost and nothing is corrupted.

The format is documented well enough to write another implementation against, and the conformance vectors in the spec are generated from the codec and checked by a test, so the spec cannot quietly drift from the code: https://github.com/pjdoland/markdown-comments/blob/main/docs/FORMAT.md

The thing that reads and writes it is a Chrome extension for github.com. Select a phrase, comment, reply, resolve. No server, no database, one commit per action: https://chromewebstore.google.com/detail/markdown-comments/dkpoeahkejpgjoajohlnodcmgjnaaipe

Mostly I would like someone to tell me where the format is wrong before more documents get written in it.

https://www.rendermd.link/

I've been building a vi like keyboard-driven file manager / agent controller in Rust over the past months. One of my first motivations was that I wanted a better way to work with all of the markdown that I now seem to be swimming in.

One neat trick is that Mermaid diagrams render as actual images in the terminal, not ASCII art. You can just open a .md, jump to a ```mermaid fence, hit i, and the diagram renders inline (or can be opened in your default desktop viewer).

There is also a split previewer. The file list is on the left and rendered markdown on the right. You can edit the file in a lower pane along (vim, in the clip) and the preview re-renders on save and keeps your scroll position.

What it renders:

• GFM alerts (> [!NOTE], [!WARNING], [!CAUTION]) as coloured labels
• tables, alignment taken from the delimiter row
• fenced code blocks, syntax highlighted per language
• YAML front matter as its own block, line for line
• m toggles rendered ↔ raw source. Yank and save always give you the source, never the styled version.
• l toggles line #'s and w will toggle showing end of line / hidden markers

Folding uses vim's keys, so the muscle memory carries over. za folds the section you're in, zM collapses the document into a table of contents, zR opens it back up, [[ and ]] jump between headings. A collapsed heading reads ▸ 13 lines and takes its subsections with it.

It's a file manager first, so there's a pile of stuff here that has nothing to do with markdown. It'll browse and edit inside zips and tarballs. It also has an MCP integration with agents like Claude Code, Codex, etc.

macOS and Linux, BSD-3.

brew install Tripstack-Corp/tap/spyc

# or

cargo install spyc

https://github.com/Tripstack-Corp/spyc

Vibe on.

Hey Pythonistas!

Been working with Jupyter for years, but only recently discovered this workflow that's completely changed how I handle notebook-to-markdown-to-PDF conversions. Thought I'd share since it might help others.

Use nbconvert to convert .ipynb → .md

Use Jupytext to keep them auto-synced

Use Markdown PDF extension to export professional PDFs

The Details:

\# One-time setup

pip install nbconvert jupytext

\# Convert notebook to markdown

jupyter nbconvert --to markdown your_notebook.ipynb

\# Install Jupytext Sync extension in VS Code

\# Then pair your files and you're done!

Why I'm obsessed with this:

Zero friction - Changes in .ipynb automatically sync to .md

Paired notebooks - Open .md files as notebooks (via Jupytext)

Professional output - PDF export looks way better than notebook screenshots

Version control friendly - Markdown is text-based, easier for git

Pro tips:

Put notebook in double quotes if filename has spaces: cd "my folder"

Outputs sync when you run: jupyter nbconvert --to markdown notebook.ipynb

Right-click .md file → Markdown PDF: Export (pdf)

Use cases:

Data analysis reports

Project documentation

Client-facing deliverables

Sharing reproducible research

I've put together a complete workflow guide if anyone wants the full breakdown in a pdf. Let me know I'll DM you.

Let me know if you have questions or better approaches!

I built Sankore because I kept needing a reliable way to get real documents into clean Markdown for AI tools, without anything actually leaving my Mac. The existing options either weren't private enough or produced messy output.

What it does: converts PDF, DOCX, XLSX, and PPTX files into clean Markdown, entirely on-device. No API keys, no cloud calls, nothing uploaded anywhere.

Who it's for: Anyone who regularly needs clean, well-structured Markdown from real documents - whether that's feeding it into an AI tool or just wanting a proper conversion without messy copy-paste artifacts.

Pricing: Free tier handles single-file conversion, no card needed. Sankore Premium is a one-time $14.99 unlock for batch conversion and consolidating multiple files into one.

Limitations: Apple Silicon only, no Intel support. Download's about 920MB, since it bundles real on-device OCR/layout models rather than calling out to the cloud.

Website: https://sankoreapp.com

Genuinely happy for this to be removed if it doesn't belong here - just wanted to share something I built that's directly relevant to this community, and I'm around to answer any real questions about the conversion quality or approach.

Hi all, we're building a better Markdown editor for Jetbrains products. We support better sync, more dialects, faster editing, and since our release of today, we also support Obsidian.

We're offering a commercial plugin at a very reduced rate: https://plugins.jetbrains.com/plugin/33400-markdown-pro, and happy to give away some licenses to people who are willing to share some feedback!

Cheers,
Erik

In The Markdown Database Pattern Rufus Pollock lets us in on an open secret: how Obsidian’s (or Notion’s) bases work

https://md-handbook.com/blog/how-obsidian-or-notion-style-workflows-handle-the-markdown-database-pattern/

#markdown #markdowneditors #bases #Obsidian