I use Hemingway on these posts, which I wrote about recently. Today I added a way to get the edited text back into the blog without replacing the whole Markdown file from the clipboard.
There is a button on the local version of each post and guide that copies it for Hemingway. It exports rich text and a plain-text version, keeping the paragraphs separate. After editing, I copy the revised post, come back here, and import the changes.
Before anything is saved, I get a word diff against the saved source. I can read what changed and then choose to save it.
The part that needed more care was everything around the prose. A guide might contain a SQL example, an image, or a table that I don’t want a writing editor to rework. Those blocks stay in the local editing session. Hemingway gets a marker for each one, and the importer puts the original block back afterwards. The frontmatter stays local too.
The markers are ugly (they start with BEAZLEYKEEP), but I can leave them alone while editing.
If one is missing or appears twice on import, the importer refuses the revision. It also checks
the unchanged title, which helps catch pasting back the wrong post.
Links need some care on the trip out and back. The export uses full URLs so a relative link doesn’t become relative to Hemingway’s site. Where those links survive in the returned HTML, the import restores their original destinations in the Markdown.
There is another check at save time. If the source file has changed since I exported it, the save is rejected and I have to start a new editing session. That’s relevant here, where I may have an agent working on the same content while I’m looking at it in another window.
The controls and the save endpoint exist only in development. The published site is still static.
The endpoint checks and browser preview/save test passed. The browser test used simulated clipboard reads, so it covered what happens after the clipboard comes back; it wasn’t a complete automated trip through Hemingway itself.