6 ms·
As another commenter noted, this is a good alternative to Nano (I too need to learn Vim). I've checked this out, and I like what I see so far. Typically my mai
by Severian 5y ago
As another commenter noted, this is a good alternative to Nano (I too need to learn Vim). I've checked this out, and I like what I see so far.
Typically my main use for text editors is for log analysis (mainly Sublime Text). This usually means I write a lot of regex for searching.
With that in mind, I do see one shortcoming in the choice of Lua as a scripting language. It's not really known for it's text processing abilities. One major shortcoming is that it doesn't have a true regex engine. This is something I use extensively.
For most of my use cases, this would require I hack together a native search in the application, and then pipe the buffer to Lua for post-processing. I'm not sure if search/replace pipelines are going to be easy to code in this manner or efficient enough to be worth it.
I use Sublime Text because it uses Python and makes this relatively easy. Or if I'm searching over thousands of logs to use ripgrep and just pipe in whatever that way since it can search 10GB in a few seconds with moderate sized regex.
Otherwise, I like the approach and the helpful commands for the user! It is definitely nice to be able to stay in a terminal instead of using a GUI to edit.
- johnsea 5y ago> (I too need to learn Vim) well, then start. What are you waiting for? E.g. here: https://danielmiessler.com/study/vim https://danielmiessler.com/study/vim. Don't miss Vim as Language.
- rcarmo 5y agoIf you're fiddling with logs, pick an editor that can handle (theoretically) unlimited file sizes -- which is something that very few mention supporting. vim will do you great stead for what you seem to need.
- Severian 5y agoYeah, buffering in an editor is important. I'll look into Vim a little more.
- Koshkin 5y agoThat’s what I have never understood - why would you want to open a log file in a text editor (when the standard tools of the trade in this case should be an “unbuffered” text viewer, which by design, can handle files of any size, fgrep, and, if you want to generate a report, a stream editor, such as sed).
- imiric 5y agoExactly. Log files are viewed in a pager, not an editor. While tools like lnav look great, many of its features can be replicated by combining smaller, purpose built tools, i.e. the core Unix philosophy. Single log view: cat | less Filters: rg | less Decompression: zless, zgrep, rg -z Timeline view: admittedly tricky, but doable with some incantation of cut, sort or reach for the big guns: awk, perl. Live operation: not quite, but tail -f and less +F go a long way. I've never once in almost 20 years of looking at log files thought I needed a SQL interface to them. I'm sure it's a powerful feature, but the above approach has served me well.
- tstack 5y agoTry out the Logfile Navigator (http://lnav.org http://lnav.org) for working with logs instead of a text editor. It can provide a lot of benefits by default, like collating messages from multiple files together, syntax highlighting, decompressing files and so on. (Sorry this is a little off topic, but there’s a lot of room for improvement for working with log files over a text editor without scaling up to a log service)
- chrisweekly 5y agoI was about to post about lnav too. It's phenomenal -- and not just for logfiles! With embedded sqlite, it really is a mini ETL powertool with all the benefits of *nix-y CLI usage and scriptabity.