[conspire] vi (was: Re: Technical Interview Performance by Editor/OS/Language - Triplebyte Blog)

[Michael Paoli]

> From: Texx <texxgadget at gmail.com>
> Subject: Re: [conspire] Technical Interview Performance by  
> Editor/OS/Language - Triplebyte Blog
> Date: Sat, 9 Mar 2019 15:15:26 -0800

> I learned visual (the REAL name for vi) from man vi.
> The name vi came from the alias students were setting in their dot files.
> Emacs is a better option than Microsoft but could use a better editor.

"Real name" might depend on the "when".  I know little of vi - at least
by any personal experience, before 1980.  By the time (1980) I was using
vi, it was already well established on Unix in University of
California environments (and likely some bit beyond?).  The command was
vi (not visual - though visual may have remained as an additional hard
link?), man page was vi(1), it was of course also a hard link to ex.
As I recall (and I think various documents support), first - at least
on Unix, there was ed, then ex, then visual mode was added to ex,
from ex one would enter visual mode by typing:
visual
(and it still works that way)
which could also be shortened to shortest unique abbreviation thereof:
vi
(but not v, as that's another command in ex/vi - the complement of g).
vi[sual] mode in ex became so popular, that code was modified such
that if it was invoked with arg0 being vi (and/or visual?), it would
start in visual mode, and the hard link(s) for vi (and visual?) were
added - so one could invoke it into visual mode from CLI by simply typing:
vi [options and/or arguments, etc.]
$ (cd /usr/bin && ls -onLid vi ex)
311624 -rwxr-xr-x 3 0 472216 Dec 30  2016 ex
311624 -rwxr-xr-x 3 0 472216 Dec 30  2016 vi
$

> I am not aware of any vi package with Bills original code.
> It appears to have been completely rewritten in several versions including
> vim and nvi.
>
> I don't know the current bad port tree well, so it might still be there,
> but none of Bills code remains in either Deb or RPM trees that I can find.

Some year(s) back ... not all that horribly long ago, ye olde classic
vi became open sourced - I think most useful search term may be
"classic vi".  I don't know that any linux distros (or BSD) have
packaged it - but the source code should be out there ... *somewhere*.
Also, not sure what license it was released under.
Anyway, by the time classic vi was open sourced, vim and [n]vi (not to
mention other clones) had long gone well beyond classic vi.
About the last place I saw classic vi, was Solaris ... I think 10 (or maybe
9) ... before Solaris dropped classic vi and switched to vim.
The BSD folks (or mostly from BSD) had by then already done a
reimplementation of vi ... on BSD systems it *is* vi, ... just not
"classic vi".  Beyond BSD it's often/typically nvi, but can also be
configured to be or be installed as vi (at least for most linux distributions
that bother to have it available at all).
The design goals of [n]vi were essentially a feature-for-feature,
bug-for-bug reimplementation of vi (with of course source code not being
so encumbered to conflict with release under, e.g. BSD, or similar licensing).
So, [n]vi is *very* close to classic vi in functionality.  Anyone who's
fingers/brain are used to flying through classic vi with great efficiency
and speed, will be highly at home on [n]vi ... not so with vim.
The number of functional differences between [n]vi and classic vi are
*very* small and minimalistic ... would rather expect that from
the BSD folks :-) ... they also avoid lots of bloat in, e.g. tar, cpio,
pax, ... whole lot 'o cruft/bloat they just don't add.  That's often
a very good thing. [n]vi is even much smaller that vim.tiny - which weighs
in at about twice the size/bloat of [n]vi.  Let's see ...
$ ls -on /usr/bin/vi /etc/alternatives/vi /usr/bin/nvi /usr/bin/vim  
/etc/alternatives/vim /usr/bin/vim.basic /usr/bin/vim.tiny
lrwxrwxrwx 1 0      12 Jan  7  2013 /etc/alternatives/vi -> /usr/bin/nvi
lrwxrwxrwx 1 0      18 Jan  7  2013 /etc/alternatives/vim ->  
/usr/bin/vim.basic
-rwxr-xr-x 3 0  472216 Dec 30  2016 /usr/bin/nvi
lrwxrwxrwx 1 0      20 Jan  7  2013 /usr/bin/vi -> /etc/alternatives/vi
lrwxrwxrwx 1 0      21 Jan  7  2013 /usr/bin/vim -> /etc/alternatives/vim
-rwxr-xr-x 1 0 2413032 Sep 30  2017 /usr/bin/vim.basic
-rwxr-xr-x 1 0 1062744 Sep 30  2017 /usr/bin/vim.tiny
$ echo $(lsb_release -d) $(uname -m)
Description: Debian GNU/Linux 9.8 (stretch) x86_64
$ ls -on /usr/bin/emacs /etc/alternatives/emacs /usr/bin/emacs24-x
lrwxrwxrwx 1 0       18 Nov  5  2015 /etc/alternatives/emacs ->  
/usr/bin/emacs24-x
lrwxrwxrwx 1 0       23 Jan 18  2013 /usr/bin/emacs -> /etc/alternatives/emacs
-rwxr-xr-x 1 0 15759624 Sep 11  2017 /usr/bin/emacs24-x
$
What (very slight) functional differences between classic vi and [n]vi?
In all my years using classic vi, and [n]vi, I think these are all that
I've noticed:
o line length limit of 1022 characters in classic vi (written in C,
   presumably 1024 byte array, 1022 characters text max + newline +
   terminating null for C string = 1024 characters - no such limit
   in [n]vi
o classic vi craps out (drops to ex mode?  Or I think it more just dies
   some type of death and exits) - if one ever has a display line that
   can't fit on the total window size - e.g. a bunch of high bit characters
   that will often take 4 (or 5?) characters each to display - have near
   around 1022 of those - that won't fit on 80x24 screen (4x1022>>80x24) -
   likewise non-issue with [n]vi
o [n]vi adds [no]leftright (the complement of vim's [no]wrap) - a  
highly useful
   thing to add, which classic vi lacks
o with [n]vi, one can invoke it without a file argument and not set a file,
   do a :w - and again without filename - and it saves it - yes, to temporary
   file, but if one subsequently crashes out (or system crashes), one can
   recover from it up to that point.  Classic vi doesn't let you do an explicit
   save to no specified at all file - so recovery is limited to whatever point
   at which classic vi did its last save - it does that semi-frequently, so
   usually one can recover to within a few or so of the most recent changes.
   Also, when one does such a save with [n]vi, it displays the (temporary)
   filename to which it saved it ... highly handy, as one can access and
   use the contents of that file (alas, neither classic vi, nor vim do that).
o classic vi - going to visual mode, it sets the cursor cvvis (if I recall
   the terminfo settings correctly), and likewise goes to cnorm
   when going to ex mode, or CLI (e.g. shell out, etc.).  Neither vim nor
   [n]vi do that - essentially - at least for typical terminals/emulations,
   that will switch to a block or blinking block cursor for visual mode (quite
   useful - making it much easier to spot where the cursor is - especially as
   one may jump around a lot in vi), and typically an underline or blinking
   underline for ex/CLI/etc. (non-visual) modes.  One of the very few things
   I miss from classic vi over [n]vi.
o writing a command out, e.g.:
   :!some_command<enter or escape>
   This is one classic vi and vim get right, where [n]vi gets it wrong :-/
   With classic vi and vim, do command like that, the outputs are just written
   straight to stdout/stderr and/or /dev/tty, etc. as applicable.  After which
   it prompts one (to do another command or return to visual mode).  [n]vi
   unfortunately gets this one wrong - it buffers and paginates the stuff -
   similar to less or more - I really don't want anything getting in the way
   between my running the command and its output - unfortunately [n]vi inserts
   itself there in buffering/paginating (window full at a time) the output.
   Not what I want.  :-/

Anyway, those are the *very* few functional differences between classic vi
and [n]vi - at least all that I'm aware of.  Classic vi also was rather
limited in size of file it could handle - but that may have been due to
typical system/machine resources at the time, rather than classic vi itself.

And ... learning vi :-) - I learned it from the VI quick reference card,
and the vi(1) man page.  Also, by the time (1980) I was using vi, it was
called and referred to as Vee-Eye, not vI, not visual.  And at least most
of the documentation I find indicates it's properly pronounced Vee-Eye, not
vI.

And, ... vi ... is optimized for efficiency of use, not speed/efficiency
of learning.  So, yes, there is a learning curve to it.  But anyone who
learns it well, for most text editing tasks (it is a text editor after
all), will be much faster and more efficient than someone in emacs doing
comparable typical text editing and a comparably well learned understanding
of emacs (at least its text editing stuff).