I got annoyed enough with Markdown tooling that I decided to build my own.
Here’s the problem: markdownlint and similar tools do the job, but they’re not exactly fast, and worse — they don’t integrate cleanly into editors because they don’t speak LSP. That means you either run them as one-off CLI tools or settle for half-baked editor plugins.
So I hacked together Quickmark, a Markdown linter written in Rust. It’s:
– Fast (because Rust)
– Built on the Language Server Protocol, so it plugs into any editor that supports LSP: VSCode, Neovim, JetBrains, etc.
– Available as both a CLI tool and an editor integration
Repo: github.com/ekropotin/quickmark
I’m calling it beta because I’m sure there are bugs hiding, and I’d love for other people to try it and break it. Feedback/issues/PRs all welcome.
That said, I do want to point something out: the “Fast (because Rust)” or “Lightning fast” tagline that’s increasingly common in Rust projects isn’t great. Just using Rust doesn’t automatically make something fast — real performance comes from design, algorithms, and benchmarks.
These days, whenever I see “Lightning fast” in a Rust project, it makes me think the author hasn’t really focused on optimization, and that the project might not actually be as performance-tuned as the claim suggests.
I got annoyed enough with Markdown tooling that I decided to build my own.
Here’s the problem: markdownlint and similar tools do the job, but they’re not exactly fast, and worse — they don’t integrate cleanly into editors because they don’t speak LSP. That means you either run them as one-off CLI tools or settle for half-baked editor plugins.
So I hacked together Quickmark, a Markdown linter written in Rust. It’s: – Fast (because Rust) – Built on the Language Server Protocol, so it plugs into any editor that supports LSP: VSCode, Neovim, JetBrains, etc. – Available as both a CLI tool and an editor integration
Repo: github.com/ekropotin/quickmark
I’m calling it beta because I’m sure there are bugs hiding, and I’d love for other people to try it and break it. Feedback/issues/PRs all welcome.
Really nice project!
That said, I do want to point something out: the “Fast (because Rust)” or “Lightning fast” tagline that’s increasingly common in Rust projects isn’t great. Just using Rust doesn’t automatically make something fast — real performance comes from design, algorithms, and benchmarks. These days, whenever I see “Lightning fast” in a Rust project, it makes me think the author hasn’t really focused on optimization, and that the project might not actually be as performance-tuned as the claim suggests.
[dead]