Editors, glibc-2.32

2020-08-28

Most people who use any form of Unix have a favorite editor. Most of them also think that everyone else is wrong (but in truth, you're all wrong...). And most Linux distros over the years have gradually catered more and more to the lowest denominator.

In the beginning, of course, there was only ed (The STANDARD editor!) and then at some point in time came Bill Joy's vi. Most people have, of course, never used the original vi. If you are on Linux, chances are good that you have encountered vim. If you are running BSD in any form then you have vi, except that you don't actually have vi, you have nvi. When 4.4BSDlite was released as the first large scale open source project, the major caveat was that much of the source was patent encumbered by AT&T, including the venerable vi editor. All of this source was therefore replaced, painstakingly, a piece at a time. The selling point of nvi at the time was that it was a "bug for bug compatible" rewrite of vi, which started with the original elvis (a vi clone) source.

For most of it's existence so far (including it's original, never released to the public form from roughly ten years ago) HitchHiker had vim. I've used vim a lot and over the years have only grown more fond of it. Sticking with it over the rather steep learning curve has been quite helpful in situations where the only editor available is some form of vi or vi clone. However, vim is not without it's issues. All forms of vi or clones of vi have a rather steep learning curve for new users. The vim source code is a rats nest of conditionals and attempts to maintain compatibility with ancient systems that only a masochist or Luddite would use. And for a console based editor it is rather slow (though nowhere near the beast that Emacs has become, a story for another time).

For ease of use and welcoming less experienced users we follow the same path as FreeBSD by offering the ee editor. It's extremely small (the entire source is a single c file) and has great ease of use due to the integrated menu bar. It isn't an especially powerful editor, but it gets the job done.

As for vim, I decided a while back that it was going to be replaced with something more lightweight and with a more "correct" code base. I tried a few times to port nvi to HitchHiker, both from the "official" nvi source distribution and also from BSD sources. The main stumbling block has been that the code assumes headers and C library routines which no longer exist in Linux.

For the solution, let's back up again by a few years. AT&T Unix is the direct ancestor to Solaris. A number of years ago Sun bequeathed the source code for the Solaris operating system to the public in the form of a CDDL licensed source distribution, giving birth to the OpenSolaris operating system in it's many forms, allowing FreeBSD to import the zfs filesystem, and effectively unencumbering historical Unix source code to the benefit of all.

Therefore, after a few days tinkering, we now have version 3.7 of Bill Joy's original ex/vi editor, which is the version that was current as of the 4.4BSDlite release, ported to and running on HitchHiker Linux. This has been a very gratifying experience overall. Some (probably many if I'm being honest) will miss certain features that they have grown used to in vim, such as syntax highlighting and visual mode. There is no plugin system (which I've never bothered to use in vim anyway...) and you're basically expected to know what you're doing. But the program is SMALL (roughly half the size of nvi, with no dependency on BDB, and orders of magnitude smaller than vim) and noticeably faster than vim when loading large files or pasting large chunks of text. You probably thought vim was fast. But you only -thought- it was fast.

You are, of course, free to install and use vim if you feel that original vi is too "limiting" for your use. Feel free to use ed for that matter, and to yell out that you're using "THE STANDARD EDITOR" while doing so. We imported ed from FreeBSD a week ago.

In other news, GNU libc (glibc) released version 2.32 this week. I'm running it already on my Arch systems but for the time being holding off on updating HitchHiker. There were a few notable deprecations in this release for functions, macros, and even a few array definitions that are considered too ancient to support. However, they actually do affect HitchHiker in a few places as we have some rather "historical" code imported into the userland tools. I spent an hour this morning fixing compilation errors when compiling mksh and ex/vi against the new library, in preparation for eventually merging it in. I'll have to check all of the other imported sources against it another day.

Interestingly, I also had to start using clang to compile these tools in Arch, as the gcc 10 series encountered an "internal compiler error", which was actually a segmentation fault, when compiling the ex/vi sources. In HitchHiker we use gcc-9.30 and these problems don't exist. Good reason to not upgrade for the time being.

Tags for this post: