Fast, Editor-Native Markdown Linting with Rust and Lsp
Posted5 months agoActive5 months ago
github.comTechstory
supportivepositive
Debate
10/100
MarkdownLspRust
Key topics
Markdown
Lsp
Rust
Developer creates Quickmark, a fast Markdown linter with LSP support, due to frustration with existing tooling.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
N/A
Peak period
1
0-1h
Avg / period
1
Key moments
- 01Story posted
Aug 24, 2025 at 6:28 PM EDT
5 months ago
Step 01 - 02First comment
Aug 24, 2025 at 6:28 PM EDT
0s after posting
Step 02 - 03Peak activity
1 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 25, 2025 at 2:09 AM EDT
5 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45008376Type: storyLast synced: 11/18/2025, 12:05:03 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.