OpenVi VS nvi2

Compare OpenVi vs nvi2 and see what are their differences.

OpenVi

OpenVi: Portable OpenBSD vi for UNIX systems (by johnsonjh)

nvi2

A multibyte fork of the nvi editor for BSD (by lichray)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
OpenVi nvi2
8 5
149 139
- -
7.5 5.2
22 days ago 3 days ago
C C
GNU General Public License v3.0 or later GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

OpenVi

Posts with mentions or reviews of OpenVi. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-02-19.
  • Portable OpenBSD vi for Unix systems
    1 project | news.ycombinator.com | 26 Aug 2023
  • Genealogy of Vim (2017)
    1 project | news.ycombinator.com | 23 Apr 2023
  • OpenVi: Portable OpenBSD vi for Unix systems
    1 project | /r/hackernews | 19 Feb 2022
    13 projects | news.ycombinator.com | 18 Feb 2022
    The behavior of the traditional vi is much different than vim and other clones. Nvi was a actually a re-implementation of the traditional vi for 4BSD (to be clean of AT&T code) and thus was originally intended to be bug-for-bug compatible, but breaking away where the original vi behavior was nonsensical or terrible.

    For vim, `set compatible` or `set cp` is close, but still not traditional vi by any means.

    A multibyte variant of the tradition vi is maintained - https://github.com/n-t-roff/heirloom-ex-vi/.

    Nvi (now on version 1.8x) is also maintained - https://repo.or.cz/nvi.git

    Nvi2 is yet another fork of Nvi, https://github.com/lichray/nvi2

    Despite the very similar names, all of these editors have a variety of different features, and are structured very differently.

    Nvi has a concept of a front-end and a back-end (which uses the BDB database). OpenVi uses the OpenBSD version of Berkeley DB which derives from 1.85. Nvi (1.8x) provides a minimal version of code also derived from that release intended from use with Nvi, and (IIRC) also provides support for using Db3/4/5. Similar situation for Nvi2.

    Nvi 1.8 has been structured where a third library layer has been added, which doesn't exist in OpenBSD's vi or OpenVi. There is scripting support (Tcl, Perl, etc.) and GUI code in the other various forks ... all of these support various different options as well.

    I should probably make a matrix of these, but you can get an idea by looking at the settable options implemented in each of the variants (as they historically include a comment to document from where the option originated):

    OpenVi: https://github.com/johnsonjh/OpenVi/blob/22c2a7022e31d91e09e...

    OpenBSD vi: https://github.com/openbsd/src/blob/master/usr.bin/vi/common...

    Nvi2: https://github.com/lichray/nvi2/blob/5fcdc13656500a8c5b4c073...

    Nvi1: https://repo.or.cz/nvi.git/blob/HEAD:/common/options.c#l52

  • Hacker News top posts: Feb 19, 2022
    6 projects | /r/hackerdigest | 19 Feb 2022
    OpenVi: Portable OpenBSD vi for Unix systems\ (22 comments)

nvi2

Posts with mentions or reviews of nvi2. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-12-29.
  • Ask HN: What was the best software that you used during 2022?
    20 projects | news.ycombinator.com | 29 Dec 2022
    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/

  • Is there an editor like emacs, vim, etc. but (solely) used in the BSD world?
    5 projects | /r/BSD | 23 Sep 2022
  • OpenVi: Portable OpenBSD vi for Unix systems
    13 projects | news.ycombinator.com | 18 Feb 2022
    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:

What are some alternatives?

When comparing OpenVi and nvi2 you can also consider the following projects:

nextvi - Next version of neatvi (a small vi/ex editor) for editing bidirectional UTF-8 text

grist-core - Grist is the evolution of spreadsheets.

heirloom-ex-vi - The Traditional Vi (vi with many enhancements from Gunnar Ritter)

src - Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list.

oed - Portable OpenBSD ed(1) editor.

signify - OpenBSD tool to sign and verify signatures on files. Portable version.

Windows Terminal - The new Windows Terminal and the original Windows console host, all in the same place!

pEmacs - pEmacs - Perfect Emacs

neovim - Vim-fork focused on extensibility and usability