[buug] [n]vi "vs." vim, etc.

[Michael Paoli]

> I created an .exrc with the following two lines:
>
> :set showmode
> :set noflash
>
> The second line turns off the flashing screen error notification. The
> first line, of course, you recommended. Between these two, I think
> that is most of what I expect of vi. I don't need to mess with
> terminfo,but thankyou for the explanation.

Ah, I see that [n]vi also has [no]flash.  Historically, I don't think ye
olde AT&T, etc. vi had that option, and nvi may not have had it earlier
on.  In any case, that does make it easier to change that behavior for
just that single application - though it also adds "one more thing" to
the application itself (arguable if that's a good thing or not in this
case).  Still, if one wants to have that impact more generally, there's
terminfo (or termcap, as applicable).

In [n]vi, historically, the output from:
:se all
fit entirely within an 80x24 display.
Alas, now I find it goes a fair bit beyond that limit - but still a lot
less than two screens full of such text.  But, egad, vim fills multiple
screenfulls with the output from that ... let's see (ugh, I don't have
vim installed ... might as well, so I can more conveniently call out
its flaws ... and update-alternatives it mostly out of the way!) ...
vim
:se all
egad ... over 6 and onto 7 80x24 screenfulls of stuff.

> It does seemthough that a compatibility
> mode should be compatible except for unarguable improvements, bug
> fixes, or non-conflictual extensions. Even nvi has those, for
> example, infinite undo. I did not realize what a can of worms I was
> opening.

[n]vi makes some very few (but significant) functional changes compared
to ye olde classic vi - mostly just removed some limitations and fixed
some bugs, see:
http://buug.org/pipermail/buug/2011-April/003731.html

As far as I'm aware, [n]vi doesn't have "infinite undo" - but vim does.
(but why would I want infinite undo?  Can't say I've ever really needed
it.
There's always:
:q!
:e!
"1p
"1P
.
u
U
:se readonly
:!chmod a-w %
26 "named" (letters) buffers
9 numbered delete buffers
1 unnamed default buffer
and of course one can work with multiple files
and one can even not tell the editor the name of the file, e.g.:
$ vi
:0r !cat file
)

> creator of vim, Bram Moolenaar.
> Bram claims that vim is"99.9% backwards compatible with Vi".
[cough].  Uhm, more like about 97 or 98.something %, but certainly not
99 or high 99.something %.  When the keystrokes and commands fly off the
fingertips at fairly significant speed and efficiently, "suddenly"
having well over 1% of them do something unexpected cuts way down on
efficiency and introduces errors and unintended consequences.

> If , as you say, he has his own way of doing regular expressions, I
> can'tsee any excuse for that.
Not "totally" different, but significantly different - we're not talking
an exception or two or three, but probably more like about a dozen or
more things done differently ("extended") with vim's REs that aren't
done that same way in any other RE program.

> But he has his own software
> "charityware" licensewhich would make it disadvantageous to do
Well, I'm not much a fan of "yet another license", but it looks like the
license is "good enough" it apparently passed DFSG criteria (it's in
Debian main), so I'm not going to nit pick over it on that (it's got
other bigger nits to be picked at).
> I expect you will never see it on the Gnu website.
Probably not a possibility until such time as it is licensed or also
licensed under GPL - and in the meantime, I think GNU's probably got
enough stuff and responsibility (and bugs) to deal with as it is.

>> ----- Forwarded message from Michael.Paoli at cal.berkeley.edu -----
>>    From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>>
>> And [n]vi, vim, etc. bits:
>> http://buug.org/pipermail/buug/2013-January/003969.html

references/excerpts:
http://buug.org/pipermail/buug/2013-January/003969.html
http://buug.org/pipermail/buug/2011-April/003724.html
et. seq.