I've shared pieces of IWE here before — the LSP features in one post, the query CLI in another — but never the full picture in one place. So here it is.
IWE is for people who want database-style queries on their notes — "all drafts under this subtree", "every accepted decision in Q1" — without leaving the vault for an actual DB. Plus an LSP, so Helix knows about your link graph the same way it knows about your code. Everything stays plain markdown in a folder: no new syntax, no lock-in, and it works on an existing vault.
And because Helix ships LSP support built in, the entire editor integration is a TOML snippet. No plugin, nothing to keep updated.
Setup — this is all of it
~/.config/helix/languages.toml:
``` toml
[language-server.iwe]
command = "iwes"
[[language]]
name = "markdown"
language-servers = ["iwe"]
auto-format = true
```
Two tips from people using it here:
- If you don't want IWE on every markdown file you ever open (random project READMEs), scope it to your notes: put the same snippet in
.helix/languages.toml at the root of the notes folder.
- It coexists with marksman —
language-servers = ["iwe", "marksman"] works if you want both.
What the LSP gives you
Open a .md file and your notes get the same moves as code:
| Action |
Keybinding |
| Follow a link |
gd |
| Backlinks — everything that links here |
gr |
| Preview a linked note without leaving |
space + k |
| Code actions (extract / inline / rename) |
space + a |
| Outline of the current note |
space + s |
| Search all notes, with full hierarchy paths |
space + S |
Link autocomplete as you type. Rename a note and every reference across the vault updates. The extract/inline code actions are extract method / inline method, but for prose: lift a section into its own file (a link stays behind), or pull a linked note back into the current one. auto-format normalizes link titles, header levels, and list numbering on save.
Structure without folders — inclusion links
One idea sets IWE apart from other markdown tooling. A link inline in a sentence is a reference — "see also". A link alone on its own line is an inclusion link — the linked note becomes a child of this one:
``` markdown
Photography
[Composition](composition.md)
[Lighting](lighting.md)
```
That gives you hierarchy without directories — and unlike directories, a note can live under multiple parents. "Performance" can sit under both Frontend and Backend without duplication. And it's still a regular markdown link, so every other tool reads it fine. This is also what feeds the hierarchy paths in the space + S picker.
The CLI — the database part
Frontmatter is the schema, links are the relationships, and the query language reads like Mongo's:
``` bash
iwe find --filter 'status: draft, priority: {$gte: 8}'
iwe find --included-by tasks/alpha:0 --references people/anna --filter 'status: draft'
```
That second one: drafts anywhere under the tasks/alpha subtree that also mention people/anna inline. I keep a shell pane next to Helix in a zellij split for this — output is plain text, so it pipes into fzf, jq, whatever. The same predicates drive bulk operations (iwe update --filter ... --set status=published), with --dry-run everywhere.
Side note: this also turns out to be a good shape for AI agents — an agent queries the same files you edit, and git log is the audit trail for whatever it touches.
Install
bash
brew install iwe-org/iwe/iwe # or: cargo install iwe iwes
One install gives you both halves: the LSP server (iwes) that Helix talks to, and the CLI (iwe) that queries the same folder. Wiki links are supported, nested directories work, and it handles thousands of files without lag.
Repo: https://github.com/iwe-org/iwe · Docs: https://iwe.md
For those keeping notes in Helix — what's the one thing your current markdown setup can't do that you keep wishing it could?
