Stop Losing Code in a Gist Graveyard: Keep Snippets as Plain Text

The clever fix you saved as a "secret" Gist a year ago is gone — not deleted, just unfindable. A code snippet kept instead as a fenced plain-text block, ```python, lives inside the note that explains it: greppable, diffable, portable, and highlighted by any renderer. The shape you keep it in decides whether you still own it.

This is not a tooling preference. It is the same ownership argument as the two pieces beside it today — a diagram written as plain text and an equation written as plain text — applied to the third rich element, code. All three are the parts of a note that don't break portability when you write them as text. A code fence is the most quietly durable of them. CommonMark, the published Markdown standard, defines it precisely: "A code fence is a sequence of at least three consecutive backtick characters (`) or tildes (~). (Tildes and backticks cannot be mixed.)" ¹ That sequence is all it takes to keep code as text.

Most people reach for a snippet store

The reflex, when you find code worth reusing, is to file it somewhere built for code: a snippet manager with folders and tags, or a GitHub Gist you paste into in seconds. Both feel correct. The code is "saved," it has a home designed for snippets, and the clever fix is no longer loose in your editor.

There is real sense in that reflex. A snippet store gives you a tidy index, a search box, and a UI that treats each fragment as a first-class object. For a while it works. You drop snippets in; you trust the store to surface them later. The store becomes the system of record for the bits of code you reuse.

And the store is genuinely good at some jobs, more on which below. The trouble is not the UI. The trouble is what happens to the snippet once it lives only inside that one store, and you go looking for it from anywhere else.

The pivot: a stored snippet is searchable only inside its own store

A snippet in a silo is findable only by the app that holds it, and a "secret" Gist is worse: it is readable through its link yet unsearchable to you. The fix you saved still exists. You simply cannot find your way back to it from your notes, your terminal, or anywhere outside that one store.

GitHub's own documentation is blunt about the searchability half: "Secret gists don't show up in Discover and are not searchable unless you are logged in and are the author of the secret gist." ²

The link-only Gist hides a second trap, and again GitHub says it plainly: "Secret gists aren't private. If you send the URL of a secret gist to a friend, they'll be able to see it." ³ So the snippet is unsearchable to you and exposed to anyone who finds the URL — the opposite of what most people assume "secret" buys them. When you actually need access control, GitHub itself routes you off Gist entirely: "If you need to keep your code away from prying eyes, you may want to create a private repository instead." ⁴

The villain here is not Gist, and it is not any snippet manager. It is the shape they share: a separate store, searchable only inside its own app, or readable only through a link you have to have kept. Every separate store is one more proprietary place your code can get stranded, and one more thing to migrate out of later. The code never moved closer to the note that explained why you wrote it.

The argument: keep the snippet as a fenced block you own

Write the snippet as a fenced code block inside your own note, and it stops being a stranded object. The language tag right after the backticks is the entire highlighting instruction, and it travels inside the plain text itself. No separate store has to remember where the snippet lives, because it lives in the note.

The mechanism is one line of the CommonMark spec: "The first word of the info string is typically used to specify the language of the code sample, and rendered in the class attribute of the code tag." ⁵ That first word, the python after the opening fence, is all a renderer needs.

Here is the whole technique. The snippet, the language tag, and the note that explains it are one piece of text:

```python
# Retry an HTTP call with exponential backoff.
# Reused this in three projects — keep it greppable next to the note.
import time

def with_retry(fn, attempts=3, base=0.5):
    for i in range(attempts):
        try:
            return fn()
        except Exception:
            if i == attempts - 1:
                raise
            time.sleep(base * 2 ** i)
```

Nothing about that block depends on a particular app. Drop the same text into a GitHub README and it highlights, because, as GitHub's docs put it, "You can add an optional language identifier to enable syntax highlighting in your fenced code block" — and "We use Linguist to perform language detection and to select third-party grammars for syntax highlighting." ⁶ Linguist, GitHub's open language-detection engine, sits at over 13,000 stars on GitHub. ⁷ An owned-notes app reads the same tag: the Obsidian community guide says "All you have to do is add the language to the top of your code block." ⁸ One info string, many renderers.

The payoff is four properties a silo cannot give you. The snippet is greppable, found in the same search as the rest of your notes — the searchability that finding notes by searching, not organizing was always about. It is diffable, so version control shows exactly which line you changed. It is portable, because it is plain text the whole way through. And it is highlighted anywhere, from the one tag. The convention is now standard enough that linters enforce it: markdownlint's rule MD040, "Fenced code blocks should have a language specified," exists for exactly this reason, and tells you "to fix this, add a language specifier to the code block." ⁹ The fenced block is the rich plain-text element you own, the same way footnotes and citations stay yours in plain Markdown.

Where a snippet manager earns its keep

A dedicated snippet manager genuinely wins two jobs a plain note cannot do, and pretending otherwise would be its own trap. The first is prefix-triggered expansion inside your editor; the second is a shared team library. These are different jobs from reuse-with-context, not worse ones — and where you need them, a manager is the right tool.

Expansion is the clearest case. VS Code's documentation describes the move: you "type a snippet prefix (trigger text), and press Tab to insert a snippet." ¹⁰ A fenced block in a note will never do that, because it does not live in your editor's completion engine. If your need is type three letters, get forty lines, that is a snippet manager's home turf, not a note's.

The second is the team. A shared, synced snippet library across a team — the job the "best snippet managers 2026" market is built around — is real value a personal plain-text note does not provide. And the line between the two shapes is not "open versus closed": even a snippet app can concede the durable storage shape. massCode, a snippet manager, says of itself, "massCode stores every snippet as a plain Markdown file on your disk with no account required," ¹¹ and its own homepage states, "Keep your data on your machine and in your control. Notes and snippets are stored as plain Markdown files, so syncing with iCloud, Dropbox, or Git stays simple and portable." ¹² The closer a manager gets to the owned-plain-file ideal, the more it agrees with the argument here. The claim is narrow: for reuse-with-context that you own and can grep, diff, and port, the fenced block in your own note wins; for IDE expansion and team libraries, reach for the manager.

The honest limits

Four caveats keep this argument exact. A plain note does not auto-expand by prefix in your IDE — that is the snippet manager's real win above, and the two tools do different jobs. Shared team libraries and team-wide sync are likewise where a dedicated manager, not a personal note, earns its keep. State both before you commit.

The third caveat is about highlighting. You still need a renderer to see the colors — the durable thing is a plain-text source any renderer can draw, not the highlighting itself. Open the same note in a plain editor with no syntax support and you see uncolored but perfectly legible code, your source intact. That is not the failure case; it is the proof.

The fourth is about the format. A fenced block follows the CommonMark info-string convention: "this is trimmed of leading and trailing spaces or tabs and called the info string. If the info string comes after a backtick fence, it may not contain any backtick characters." ¹³ But the spec is explicit that highlighting is a renderer behavior, not a guarantee of the format — it "does not mandate any particular treatment of the info string." ¹ You own the portable source; the colors are a courtesy each renderer chooses to extend.

What to do tomorrow

Three moves turn a stranded snippet into one you own, and none needs a new app. Paste the next reusable snippet into the note that explains it, tag the fence with its language, and reserve the snippet manager for the two jobs it actually wins. The shape is the decision; everything else follows from it.

1. Keep the snippet in the note, not a silo. When you save a fix worth reusing, paste it as a fenced block beside the prose that says why — so search finds the code and the reason together.
2. Always tag the fence. Put the language as the first word after the backticks (```python); that one token is what every renderer reads for highlighting. markdownlint's MD040 exists to remind you. ⁹
3. Use a snippet manager for what it's best at: prefix-triggered IDE expansion and shared team libraries. Match the tool to the job, not the job to the tool.

The same logic is why exporting your notes should never feel like a rescue: if the snippet was a fenced block from the start, it was never trapped, so there is nothing to escape from. A snippet kept as plain Markdown on your own device is text you already own — greppable and diffable next to the note that explains it, highlighted by any renderer, portable to any tool.

Frequently Asked Questions

These are the questions developers actually ask when they go looking for the fix they saved and cannot find it. The short answer threads through all of them: keep the snippet as a tagged fenced block in your own notes, and reserve the snippet manager for IDE expansion and team libraries.

How do I store reusable code snippets in my notes with syntax highlighting?

Paste the code as a fenced block and put the language as the first word after the opening backticks. CommonMark says "the first word of the info string is typically used to specify the language of the code sample, and rendered in the class attribute of the code tag." ⁵ Any renderer reads that tag and highlights from it.

Are secret gists searchable, and can anyone see my secret gist?

No, and yes. GitHub's docs say "secret gists don't show up in Discover and are not searchable unless you are logged in and are the author of the secret gist." ² They also warn that "secret gists aren't private. If you send the URL of a secret gist to a friend, they'll be able to see it." ³

How do I get syntax highlighting in a Markdown code block?

The info string's first word does it. GitHub's documentation: "You can add an optional language identifier to enable syntax highlighting in your fenced code block," and "we use Linguist to perform language detection and to select third-party grammars for syntax highlighting." ⁶ Write ```sql and a Linguist-aware renderer applies SQL highlighting from that single token.

Do I need a code snippet manager?

Only for two jobs a plain note cannot do. A manager wins prefix-triggered IDE expansion — VS Code lets you "type a snippet prefix (trigger text), and press Tab to insert a snippet" ¹⁰ — and shared team libraries. For reuse-with-context you can grep, diff, and port, a tagged fenced block in your own notes wins.

Will a fenced code block always render highlighted?

Not guaranteed — highlighting is a renderer behavior, not a format promise. CommonMark is explicit that the spec "does not mandate any particular treatment of the info string." ¹ A renderer-less editor shows uncolored but fully legible code, your source intact. The portable thing is the plain text; the colors are each renderer's courtesy.

Isn't a snippet manager just better than notes for code?

For two jobs, yes; for ownership, no. Even a snippet manager can concede the durable shape: massCode "stores every snippet as a plain Markdown file on your disk with no account required." ¹¹ The honest split is prefix-expansion and team sync for the manager, reuse-with-context-you-own for the fenced block in your notes.

The snippet you can grep is the snippet you still have a year from now. Steph Ango, who has argued the file-over-app case more cleanly than anyone — "File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read" ¹⁴ — names the principle underneath all of it: "Apps are ephemeral, but your files have a chance to last." ¹⁵ A snippet in a silo is the app. A fenced block in your own note is the file.

To keep your snippets as the plain text you already own, mnmnote.com lives in your browser.