Requesting and Shaping New Features in Lnav

The screen glows, lines of log data pouring in faster than you can scroll. You need answers, not noise. This is where Lnav earns its place—but it could do more.

Lnav is already a powerful log file navigator, merging multiple files, highlighting patterns, and offering SQL-like queries directly against your logs. It strips away the cruft from troubleshooting. But the moment you push it into heavy production workflows, you start thinking about the next step. That’s where the Lnav feature request process matters.

Every new Lnav feature request echoes from real work: better filtering on complex JSON logs, native integration with structured metrics, faster indexing for massive datasets. Engineers want precise regular expression search without lag. They want bookmarks, saved queries, and portable filter configs. Managers ask for real-time stream support so logs in motion can be inspected without writing temp files. Others push for richer export capabilities—JSON, CSV—without losing formatting.

Submitting a Lnav feature request isn’t complicated. The official GitHub repository tracks discussion, and the maintainer responds directly to well-documented proposals. A strong request includes exact command syntax, example data, and measurable performance goals. Source code references help, especially when you know the section that needs modification. The more concrete, the faster your idea gets traction.

Priorities shift fast in active projects, but well-argued requests stand out. Lnav’s core strength—operating directly from the terminal—is worth protecting while expanding. Features that don’t weigh down performance or bloat the interface tend to win. Think smaller, faster, more precise.

If you want to test your own workflow beyond requests, there’s a faster way. Spin up your logs, stream them, and see what’s possible in minutes. Go to hoop.dev and run it live—no waiting for the next release.