The markdown round-trip

Architecture — part 2 of 13

Markdown exists only at the editing boundary; storage and build never see it:

  • lib/markdown_parser.rb (text → blocks) parses the author's markdown once, at save time. The /markdown/ cheat-sheet page is generated through this same parser, so the documented syntax can't drift from the implemented one. The two pictures its examples show are drawings in assets/cheat-sheet/: to the parser that folder is the sheet's media, so an example names them bare as a post names its pictures, and like everything under assets/ they are published as they stand (/assets/cheat-sheet/landscape.svg, portrait.svg).
  • lib/markdown_writer.rb (blocks → markdown) is the mirror: it renders a stored post back into editable markdown for blog.sh edit. The output is always re-parseable, though ties between overlapping formatting spans may come out normalized. Content markdown can't express (imported embeds; a link card anywhere but the first block) is protected by a count-based loss check in the CLI before saving. The card a post OPENS with is the exception: the CLI lifts it into the front matter as link:/link_title:/link_description: and puts it back on the way in, so it round-trips through the editor untouched.
  • The count-based check compares block types, so it sees a block that disappeared but not an attribute that did. Where an attribute has no markdown form and cannot be re-typed by the author -- a video's imported poster -- the CLI carries it over from the stored post instead, matching on the video's file or URL. Anything added to a block that markdown cannot write down needs the same treatment.
  • The importers write the same schema through the shared lib/post_writer.rb, so an imported post and a hand-written one are indistinguishable downstream.