nvi2 VS kakoune

nvi2 [0]: I got to like the simplicity of nvi when installing Void Linux on my laptop, but it had some annoying bugs that made me switch to nvi2. In general, it feels like `good' software; powerful enough by virtue of being a 1:1 vi clone with a few crucial improvements (multibyte, multi-undo, etc.), but simple enough to hack on if I miss some feature. Though no autocomplete means it's not suitable for more verbose languages, like Java.

QuickJS [1]: qjscalc is my go-to scientific calculator, and qjs my go-to JavaScript implementation for simple programs. The C interface is very nice to use, too. All in all, it feels very much like a "complete" engine, even if not quite as fast as one with JIT.

w3m [2]: Somewhat lacking as a web browser, but a very good pager. Would take it over less any day. Also has the best table display of any text-mode browser, supports inline images, and is rather extensible.

Wine [3]: It's gotten so good that I no longer have to dual boot Windows. Still not perfect, but definitely on my list of "good software".

[0]: https://github.com/lichray/nvi2

[1]: https://bellard.org/quickjs/

[2]: https://github.com/tats/w3m

[3]: https://www.winehq.org/

Don't confuse OpenVi/OpenBSD-vi, nvi1, and nvi2. These are all different programs that share the same heritage.

OpenVi is derived from OpenBSD vi, which derives from nvi version 1.79, released in 1996. There has been 25+ years of independent development as part of the OpenBSD base system and has diverged greatly in that time, with the development going in a different direction.

Nvi1, currently on version 1.8x, is maintained at https://repo.or.cz/nvi.git - I believe the latest version of this editor does have multibyte support, but this is not the OpenVi/OpenBSD version of the editor.

Nvi2 shares heritage as well but also, quite far removed from the original code, is actively maintained at https://github.com/lichray/nvi2 and also includes multibyte support.

(IIRC) the multibyte support in both Nvi1 and Nvi2 derives from nvi-m17n, developed as part of the KAME project by the late itojun - http://www.itojun.org/itojun.html ... the last update to nvi-m17n was about 3 years ago, and is available at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files

Currently, optimizing for size using link-time garbage collection with GCC 11.2 on an x86_64 glibc Linux system gives a good idea of the changes over time and the different direction these editors have taken. OpenVi is also simplified in structure and does not have the three levels of abstraction of Nvi 1.8x - there is no library interface layer.

For OpenVi, the compiled binary is 280K, and for Nvi1 (nvi-1.81.6-45-g864873d3) the compiled binary is 528K (36K for vi, 528K for libvi).

OpenVi has a single configuration standard with no dependencies beyond curses.

Nvi1 has many options beyond trace/debug ("widechar" "gtk" "motif" "threads" "perl" "tcl" "db3/4" "internal-re") - so at least 255 different build variations are possible.

(I've not yet built Nvi2 myself on Linux so I can provide an actually fair comparison yet, but I will, and I'll summarize the data in an FAQ section of the README)

Nvi1 (https://repo.or.cz/nvi.git) looks like:

Helix's modal editing is based on Kakoune's modal editing which is like an evolution to Vim's modal editing. You can think of it as being always in selection (visual) mode. https://github.com/mawww/kakoune?tab=readme-ov-file#selectio...

And while it doesn’t use the sam language precisely, I think in the broader “postfix Vi with visual feedback” category Kakoune[1] also warrants mentioning. The command language, in my experience, feels much more logical than that of Vis coming from a blank slate (things might be different if you come from Vim, but even when I used Vim regularly I never used the editing language that much exactly because I could never remember the damn thing).

And having mentioned Kakoune it’d probably be unfair to then not mention Helix[2]. It has a very similar editing language, but it’s a fairly anti-Unix everything-bolted-in affair on the inside (“everything works out of the box” being the advertising take) compared to Kakoune’s Acme-inspired no-scripting scripting (there’s an ex-style command to exec a user program that can then drive the editor over stdio RPC, a set of hooks, and that’s it). So if you’ve come for the Plan 9 feels, I don’t expect Helix to be that appealing. It’s still a good editor, nevertheless.

[1] https://kakoune.org/

[2] https://helix-editor.com/

You can take a look at kakoune. The source code (excluding documentations, test cases, customizations etc.) is less than 40k. It is, IMHO, a show case of a C++ project in use.

> I wonder if the author has ever heard of vis[0]

Yes.

https://github.com/martanne/vis/wiki/Differences-from-Kakoun...

https://github.com/mawww/kakoune/wiki#onboarding

> which imho fulfills far better each one of those premises

Not very motivated for such a harsh critic..

I've been using Vim for years, but if there was one thing I could change, it would be the verb-noun order. The Kakoune[1] editor behaves mostly like Vim, but where Vim has `dw` as "delete word", Kakoune has it backwards: `wd`.

It might sound minor, but by placing the range first, Kakoune can give a preview of what will be changed. The longer or more complicated the command, the more this feature shines.

Strictly better as far as I know. A shame my muscle memory, and all default installations, are still stuck with Vim.

[1] https://kakoune.org/

Helix is a postmodern text editor built in Rust built for the terminal. It is inspired by Kakoune, another Rust based text editor. Helix has got multiple selections, built-in Tree-sitter integration, powerful code manipulation and Language server support.