A Saved Search Is Just a File You Own

A smart folder is a saved query wearing a folder costume. The folder holds nothing; the query does the work, and the query is the asset. Keep that query as plain text you own — a one-line search, a config file, a shell alias — and it outlives the app you wrote it in.

This is the follow-on to a simpler claim: that you should find your notes by searching, not by filing them into folders. That piece argued the mechanism — search beats organizing. This one argues the artifact. Once you accept that a search finds the note, the next question is who owns the search. The honest answer, almost everywhere, is the vendor. This post is about taking it back.

What is a saved search, really?

A saved search is a stored query plus a place to keep it. The query is the only part that matters — a pattern, maybe a few flags, run against your notes. A "smart folder" is that query with a folder icon on top. Nothing lives inside it; it re-runs the query each time you open it.

The folder is theatre. The query is the thing you own.

That distinction is the whole post. When the query lives as text you can read, copy, and version, you own it. When it lives as a definition inside an app's interface — a row in a database you never see — you own the output for as long as the app runs, and nothing afterward. The smart folder is convenient. The saved query is durable. Those are not the same property, and most tools quietly sell you the first while implying the second.

Why does the query, not the folder, hold the value?

Because the engine behind the query is older than every note app and owned by no one. grep shipped in Unix in the 1970s, and POSIX — the long-standing operating-system standard — later codified the search primitive plainly, in a vocabulary every Unix-like machine carries. No vendor invented it; no vendor can take it away.

The standard's own words are blunt: "grep — search a file for a pattern," and "The grep utility shall search the input files, selecting lines matching one or more patterns." ¹

So the query you write is expressed in a public vocabulary. Run it against a directory of plain Markdown files and you reproduce, with no proprietary index to build or maintain, exactly what a smart folder gives you: every note that matches, recomputed on demand. The folder was never the value. The query — written in a language nobody owns, run over files you control — is.

This is the same instinct Steph Ango, Obsidian's CEO, named in his essay File over app: "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." ² A saved query is a retrieval artifact. "Easy to retrieve" is the whole job. Keep the retrieval instructions as a file, too, and the philosophy holds end to end. "Apps are ephemeral," Ango writes, "but your files have a chance to last." ³

The worked example: ripgrep as one saved query

Here is the principle in one concrete tool. ripgrep (the rg command) is a modern search utility, and it behaves like a smart folder out of the box, with no index to build or maintain. Point it at a folder of notes and it surfaces matches the way a saved view would.

Its documentation states the defaults: "ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files." ⁴

Read that as a filter. Point it at your notes and it already ignores the noise and surfaces the matches — a live, recomputed view, exactly what a smart folder promises. One command:

# Every note that mentions a project, recomputed each time you run it.
# No index. No app. Just a query over plain-text files.
rg 'project: aurora' ~/notes/

That line is the entire saved search. It is portable: it runs anywhere rg is installed, copies into a note or a README, and carries no hidden state. ripgrep's own docs make the case for consolidating around one such query rather than a pile of per-app search features — it "can replace many use cases served by other search tools because it contains most of their features and is generally faster." ⁵ One query you own, instead of N proprietary views you don't.

The same idea holds for a plain grep invocation, a find … | grep pipeline, or any query you can write down. rg is the example, not the requirement.

How do I store the query so I actually own it?

Store the query in one of three plain-text forms, in rising order of permanence: the one-liner you copy, a config file the tool reads, or a named shell alias. Each is text you can read, edit, version next to your notes, and carry between machines.

The output may be less convenient than a live smart folder. But the definition is something you can export — which a smart folder usually is not.

The first three rows are files you own. The fourth is a view locked to one app. That is the contrast, and it is about form, not brand: a query you can read beats a query you can't.

How do I write the config file?

A config file is the durable middle option, and it is gloriously simple. In ripgrep, the format has exactly two rules: "1. Every line is a shell argument, after trimming whitespace. 2. Lines starting with # (optionally preceded by any amount of whitespace) are ignored." ⁶ That is the entire specification. A saved query becomes a readable, commentable text file:

# ~/.ripgreprc — my standing search defaults.
# Comment freely; blank lines are fine.

--smart-case
--type-add=note:*.md
--glob=!archive/

There is no magic in that file. "In particular, there is no escaping. Each line is given to ripgrep as a single command line argument verbatim." ⁷ The file is the flags you would otherwise type, frozen. And it is meant to be annotated — ripgrep's author, Andrew Gallant, is explicit: "Comments are encouraged so that you remember what the config is doing. Empty lines are OK too." ⁸ A smart folder can't tell you, six months later, why it was defined the way it was. A commented config file can.

Gallant's stated reason for supporting config files is itself the ownership argument in miniature: "It is possible that ripgrep's default options aren't suitable in every case. For that reason, and because shell aliases aren't always convenient, ripgrep supports configuration files." ⁹ The config and the alias are two forms of the same thing — a saved query you keep.

Does a saved config lock me into one behaviour?

No — and this is the property a smart folder can't match cleanly. A saved query sets your defaults, but you can still override any of them, once, on the spot, without editing the saved file. The standing query stays; today's exception is just for today.

In ripgrep the mechanism is exact: "This works because ripgrep's configuration file is prepended to the explicit arguments you give it on the command line. Since flags given later override flags given earlier, everything works as expected." ¹⁰

So your config is a reproducible default, not a cage. The standing query loads every time; the ad-hoc flag you type today wins for today and changes nothing permanent. You get the repeatability of a saved search and the freedom of a one-off — both, from a file you control. A locked vendor view tends to give you one or the other.

# ~/.ripgreprc says --smart-case. For this one search, force case-sensitive:
rg --case-sensitive 'API' ~/notes/
# The config still applies tomorrow. Nothing was overwritten.

Common mistakes

These are the honest failure modes, the trade-offs the ownership reframe does not erase. A saved query is more portable and versionable than a smart folder — not necessarily faster to glance at, and not a cure for everything you'll want to find. Four mistakes account for most of the disappointment, and each has a fix.

1. Treating "portable" as "more convenient." A live in-app smart folder updates visually as you type and needs no terminal. That convenience is real. The trade is convenience-now versus durability-later: a saved query is more ownable, not more glanceable. The thing worth distrusting is the locked, non-exportable view — not every app feature.
2. Expecting search to find what you never wrote. A saved query has a real recall ceiling. In a now-classic study, David Blair and M.E. Maron tested a full-text system holding "about 40,000 documents with 350,000 pages of text"; recall "averaged only about 20%" — "retrieving only about 1 in every 5 relevant documents! And this was with trained researchers." ¹¹ You cannot query for a note whose words you can't recall. Pair search with good filenames and one index note; a little deliberate structure raises recall where a content query can't reach.
3. Reading rg as a terminal-only prescription. The principle — a saved search is a stored query you own — holds for a grep script, a find pipeline, your operating system's desktop saved searches, or your note app's own saved-search box. Those non-terminal on-ramps give convenient output; the catch is that their definition often can't be exported. Use whichever on-ramp fits; just keep the definition as text where you can.
4. Forgetting to point the tool at the file. ripgrep does not auto-discover a config file. If the RIPGREP_CONFIG_PATH environment variable is not set, the .ripgreprc is silently ignored and your saved query never loads. Set it (export RIPGREP_CONFIG_PATH="$HOME/.ripgreprc") before you trust the default. Every tool has an equivalent step; the reproducibility depends on it.

How this works with notes you own

A saved query is only as portable as the notes it runs against. If your notes are plain Markdown files stored locally on your own device, the query that finds them is also just text you own — a one-liner, a config file, an alias — and nothing proprietary has to index them.

That is the architectural point, not a product one: when both the notes and the search live as files under your control, your retrieval layer travels with you across machines and outlasts any single app. MNMNOTE keeps notes as plain Markdown on your device for exactly this reason — so the search that surfaces them can be a file you keep, too.

Frequently asked questions

The short version: a smart folder is a saved query, and you own the query only when it lives as text. Store it as a one-liner, a config file, or a shell alias next to your notes, and pair it with good filenames so it can find what you wrote. These are the questions readers ask most.

How do I save a search or smart folder for my notes that I actually own?

Store the query as plain text next to your notes: a one-line command you paste into a note, a config file the search tool reads, or a named shell alias. All three are readable, editable, version-controllable, and portable between machines — unlike a vendor smart folder, whose definition usually can't be exported.

What is the plain-text alternative to a smart folder?

A stored query in a plain-text file. A "smart folder" is a saved query with a folder icon; keep the query itself — an rg one-liner, a .ripgreprc, or a shell alias — and you have the same recomputed-on-demand view, expressed in a language no vendor owns, over files you control.

Is a smart folder the same as a tag query?

They are cousins. A tag query and a smart folder are both saved searches over your notes — one keyed on tags, one on content or metadata. The deeper tags-versus-folders decision is about how you mark notes; this post is about owning the query that reads those marks back.

Why not just use my app's built-in saved search?

Use it for convenience — but know what you own. A built-in saved search gives you handy output while you stay in that app. The risk is that its definition lives in the app's internal store and often can't be exported. Keep a plain-text copy of the query so the search survives the app.

Do I need to use the terminal for this?

No. The terminal is one worked example because tools like rg make the "saved query as a file" idea unusually clean. The same principle covers your operating system's desktop saved searches and your note app's search box. The rule is not "use a terminal" — it is "keep the query's definition as text you can read and carry."

Won't a saved query miss notes I'm looking for?

It can. Full-text search has a documented recall ceiling — Blair and Maron measured roughly 20% recall even with trained researchers ¹¹ — because you can only search for words you remember writing. Pair the saved query with descriptive filenames and one index note; structure and search together recall far more than either alone.

A folder holds nothing; the query holds everything — so keep the query as a file, and your search outlives the app that helped you write it. If you want notes whose search can be a file you own, too, MNMNOTE keeps them as plain Markdown on your own device — mnmnote.com.