Code Blocks in Markdown Studio

Code blocks are where plain-text editors earn developer trust: the editor must display the code cleanly, never reformat it, and hand it back byte-for-byte. Markdown Studio handles this with a dedicated CodeBlockView — a fenced block that renders with syntax display and a copy button, while the file on disk keeps the code verbatim inside triple backticks. Around it sit the blocks that make notes usable for engineering work: local images and a drag handle for rearranging everything.

The CodeBlockView

Every code block in the editor is a CodeBlockView, which gives it three properties that matter:

• Clean syntax display — monospaced, consistently spaced, no editor chrome competing with the code.
• Verbatim fidelity — indentation, tabs and blank lines are preserved exactly; the block is a window onto plain text, not a reformatter.
• One-click copy — a copy control on the block puts the exact code on the clipboard, so a snippet in a note is one click from a terminal, a REPL or an issue comment.

Create and use a code block

1. Type the slash key on an empty line and choose Code block.
2. Paste or write the code into the block — it appears in the monospaced view immediately.
3. Set the language tag on the block so the syntax display matches the code — bash, python, sql, json and the rest.
4. Use the copy button whenever the code is needed elsewhere.
5. Keep typing below the block as usual; Enter inside the block stays inside the code, Enter outside starts a new paragraph.

The language tag matters beyond the editor too: it is written into the opening fence in the .md file, so GitHub and every static site renderer highlight the block the same way.

Why fidelity is the whole feature

A code block is only useful if the code that comes out is the code that went in. That is why the block never wraps long lines silently, never converts indentation, and never smart-quotes a string. What you see in the CodeBlockView is exactly what the .md file holds between its opening and closing fences — the fence itself, plus the language tag you set, round-trips through git diffs, static site generators and CI scripts unchanged.

Pair code blocks with tables for config matrices and task lists for runbook steps — both are covered in task lists and tables.

A runbook note, put together

The combination shows its worth in the document every technical team eventually writes — the runbook that must work at 3 a.m.:

1. H1 with the service name, H2 sections for check, fix and escalate.
2. Code blocks for every command, each with its language tag so the syntax display makes typos visible.
3. Task lists for the sequential steps — checkboxes record progress even mid-incident.
4. A table mapping symptom to likely cause.
5. Local images for the dashboard screenshot that is always the first thing needed.
6. The drag handle to reorder when reality reveals that step four happens before step two.

Because every command is verbatim in a fenced block, the person following the runbook can copy each one straight to a terminal — no retyping, no transcription errors, no "was that a hyphen or an em dash". When the procedure changes, the file updates in git like any other code, and the diff shows exactly which step was rewritten.

Choosing what becomes a code block

Not everything monospaced belongs in a fence, and the judgment calls are quick:

• Anything a human will copy — commands, queries, config, API payloads — goes in a code block. The copy button exists precisely for this.
• Anything you want diffed goes in a code block; fences keep the content on single lines, so git changes read cleanly.
• Filenames and paths inside prose stay inline — a fence isolates, and a path inside a sentence does not need isolation.
• Terminal output worth quoting goes in a block with its own fence, separate from the command that produced it, so cause and effect stay distinguishable.

The one habit to avoid is nesting prose inside code blocks — a fence with explanation sentences in it defeats both the syntax display and the copy button. If a block needs commentary, the commentary lives in the paragraph before it, where every Markdown tool can see it.

Images and reordering around the code

Engineering notes rarely stay prose-only:

• Local images — insert with the slash menu or drag the file in; images are blocks like any other, sitting beside paragraphs and code.
• Block drag handle — every block carries a handle for dragging it up or down the document. Move a snippet next to the paragraph that references it, or pull an architecture screenshot above the code it explains, with one drag.

Reordering is the quiet workflow win: instead of cutting and pasting text and hoping the fences survive, you drag whole blocks — code, image, paragraph — and the Markdown rewrites itself correctly.

Images deserve one practical note: they are referenced as local files, so the note and its images travel together as a folder. Keep the images beside the .md file or in a subfolder next to it, and the note renders identically in Markdown Studio, on GitHub and in any static site build — no hosting account, no CDN, no broken link when a service shuts down. The same local-first logic applies to everything else in the file: a note with its images is a self-contained folder you can zip, sync or hand to a colleague on a USB stick.

What to explore next

• Slash commands — the menu that inserts code blocks and everything else.
• Task lists and tables — structure for runbooks and checklists.
• Export to DOCX — send the note, code included, to Word users.
• Rixoffice Markdown files — how .md fits the suite's format story.