[buug] vim (& [n]vi?) annoyances, etc.

[Michael Paoli]

[n]vi annoyances?  Far too short to bother to put together a list.  I've
only come up with two:
:[line(s)]w !command
Don't paginate or filter the above, just write it straight - stdout to
stdout, stderr to stderr.  If I wanted to paginate it I'd do something
like:
:[line(s)]w !command | $PAGER
I think the above is the only case I'm aware of that vim (yuck) gets
right, and [n]vi gets wrong.  Ye olde classic vi gets it right - but it
has some serious bugs/limitations, which were fixed in [n]vi.
And: visual mode: tput cvvis.  When going into visual mode, [n]vi should
do the equivalent of tput cvvis, and when leaving it, tput cnorm.  It
doesn't.  Classic vi got that one correct.
That's it :-).  Everything else with [n]vi is perfect ;-).
Hey, keypad and cursor (e.g. arrow) keys?  That's a feature, not a bug.
Don't need no steenkin' non-ASCII keyboard input for a text editor -
that would just cause user to become addicted to some keys that may not
be present on all keyboards - so best not to use them :-).  Really only
need some of those funky keys for, oh, like X (e.g. some kind of Meta
key), some operating systems that use them to switch virtual consoles
(like Linux - and when on the console), or that nice big operating
system called Emacs - but too bad Emacs doesn't supply a good text
editor.

Bugs [n]vi fixes over classic vi:
Not necessarily a comprehensive list, but at least the most obvious I've
noticed:
Classic vi: bugs/limits fixed in [n]vi:
line limit 1,022 characters ("obviously" someone limited their C strings
to 1,024 bytes - line always ending with \n and string terminated by \0,
thus 1022 character line limit).
If the line doesn't fit on the display (e.g. let's say one has a 1,022
character line of \301 A1 - that's control-A + high bit set, in vi that
displays as M-^A - taking up 4 characters on the display, well 4*1022 >
80*24, so something like that won't fit on some displays - with classic
vi, it would (I forget which) either crash and core dump, or drop to ex
mode.
Likewise classic vi would crash on files that were "too big" (for not
very large values of "too big") - I'm sure there are some practical
limits (which may depend on resources), but that's mostly not an issue
for [n]vi.
Classic vi also couldn't handle too long of a command input line (e.g.:
:!...)
Cool minimalistic features [n]vi adds over classic vi:
:se [no]leftright
A sorely needed option missing from classic vi (really needed when one
wants to see things aligned with lines longer than display width -
without such option in classic vi, there are hackish work-arounds using
things like cut(1) paste(1) or the like, vim likewise adds :se
[no]wrap).
[n]vi is really cool when one fires it up and is working in buffer, but
hasn't named a file to work on - it uses and displays the temporary
file name it uses for that, and if one does :w it writes to that file -
one can then, e.g. cat that file, or if one crashes (e.g. someone kills
power to the computer), one has consistent written out copy of file to
recover (vi -r) from from whence one wrote (:w) it out - no ambiguity
as to when [n]vi flushed buffer to disk and point from which one would
be able to recover.  This also avoids the slight annoyance of, if one
has habit of doing :w, otherwise getting an error as there's not a
(named) file to write to ... and the filename is displayed when :w is
issued, so it's also quite clear that it's the temporary file.
There's some other slight additional bits - but none that I
particularly notice.  [n]vi does pretty well document what it
adds/changes relative to classic vi - and it is quite minimal - as it
well should be, because there was little wrong with classic vi.  :-)

Oh, and another vim annoyance! (forgot to note this one earlier):
vim displays many characters - e.g. those with ASCII high bit set - in
ways that, at least by default, often totally mess up the display, and
make it exceedingly difficult to edit, as not only are things not
displayed accurately, but where one's editing in the file, and where
the cursor is displayed are inconsistent, and generally messed up - such
never was an issue with classic vi, and isn't an issue with [n]vi , so
again, another vim annoyance.

> From: "Ian Zimmerman" <itz at buug.org>
> Subject: Re: [buug] vim (& "certain" Linux distributions) annoyances
> Date: Thu, 07 Apr 2011 17:19:54 -0700

> Michael> Oh yeah, ... and some other serious vim annoyances ... but I'll
> Michael> add 'em to my list and save 'em for another time ;-).
>
> Someone should post a similar list for nvi, LOL.  I am not volunteering,
> but the way it handles keypad and cursor keys (ie. it doesn't) would be
> a start.

Remember back in college or so - when instructor would allow notes for
a test - all the notes one could fit on both sides of a standard 3x5"
card?  And of course many folks wrote very small.  I could fit all my
[n]vi annoyances on the back of a single standard sized postage stamp.
For vim, both sides of a 3x5" card may not suffice (but a 5x8" card
probably would).