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.
Try out the Logfile Navigator (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)
I 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.
If 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.
That’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).
Exactly. 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.
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.