Aside from the bitmap font, this looks pretty much the same as it does now lol

I'll also add I used lnav more recently for viewing logs from many small lab devices centralized via syslog, it was extremely lightweight and effective.

Wow, the GitHub mobile app doesn't preview PNGs. TIL

> Kinda neat but I had trouble using it. Not sure what it is doing or what it is even showing me.

Can you elaborate a little more? lnav behaves like a pager with the conventional hotkeys for basic stuff. I'm not sure what else you are expecting.

> Also a nitpick but the colors are quite garish

I enjoy colors, so there's a lot going on by default. There are several themes builtin. You can configure the "grayscale" theme by running:

    :config /ui/theme grayscale

Just be aware of the risks! https://security.stackexchange.com/questions/38128/what-are-...

In my opinion logfile navigator is much better than grafana, I use grafana to view a lot of microservices docker logs, but it's too tedious for me (even if depends on your specific use case).

This one, on the other hand, is cleaner and lets you find what you're looking for quickly. And, last but not least, is much lighter.

Currently working exactly on that https://gitlab.com/makapuf/treewalker (even if it could always use some love)

I use vnlog and feedgnuplot to massage and plot data on the console all the time. It's even less than a tui, but might be what you want.

Oof, sorry you had such a bad experience.

> but there is no obvious way to exit. I tried Q,q

It's not very responsive during initial indexing, which is something I need to improve. Pressing `q` should work to exit in general, though. Pressing CTRL-C three times in quick succession will force quit it.

It would help to know which version you tried. Things have gotten better over the years.

> I tried `man lnav` in separate terminal - but no man page is provided.

A man page exists, but only contains basic information. The builtin help text is much more extensive and can be viewed by running:

    lnav -H

> `ps` shows 3 processes which would not die with SIGTERM, have to `kill -9`.

Older versions of lnav would use readline for the prompt and had to run it in a separate process because of "reasons". More recent versions have a custom prompt and don't require the extra processes.

I don't know how you got it but q and Q closes it, and there is a man page on my system at least.

The problem with GUIs is that AFAIK they need to be installed on the machine the logs you are reading are on so a heavy install on a server.

every editor ever :)

According to the linked homepage, the memory usage seems decent (few hundred megs for most use cases when working with a 3.3G logfile). There's a screenshot with various tasks and what the peak memory usage is.

At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.

> At that time lnav basically just kept everything in memory.

lnav has never really kept the contents of files in memory. It does build an index of every line in a file. One exception is that it will decompress small gzip files and keep them in memory as a tradeoff from decompressing on the fly.

The memory consumption has never been a problem for me. So, it's not something I've ever focused on.

Yep, I would say the stiffest competition for lnav is the old tools[1]. I would just hope folks could have an open mind and give "new" things a chance (although lnav has been on github for 17 years).

[1] - https://lnav.org/2013/09/10/competing-with-tail.html

Speaking as the author, I too wish it was written in Rust. But, I started it in 2007 when I needed to get practice with C++ for work. At this point, there's so much code in lnav, rewriting would be a long process. There are some sub-components[1] that are written in Rust though.

A new project called logana[2] is written in Rust and is headed in a good direction. Use/contribute to that if you're really interested.

[1] - https://github.com/tstack/lnav/tree/master/src/third-party/l...

[2] - https://github.com/pauloremoli/logana/

How would this improve the functionality of lnav?

I sense an opportunity for you.

Memory safety doesn't mean it's safe. And C++ doesn't mean it's unsafe.

Browsers are in C++, do you not use them? Curl is in C, do you not use it? Kernel is C...