[sf-lug] file limit in vi?

Rick Moen rick at linuxmafia.com
Thu Sep 27 12:12:44 PDT 2007

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> E.g. for "too large" of a file, some or many edit options may be far
> too slow and time consuming to be practical; the time to perform
> various operations may, in many cases, show a worse than linear
> relationship to file size - at least past some file size threshold.

This is why /usr/bin/less rocks:  You can use it to page back and forth
(and search) through a very large file with extreme speed.  _If_ you 
find a spot that really needs editing, you type "v" to load that file
into whatever text editor you have defined by environment editor
"VISUAL" (i.e., your preferred screen editor), or, if that is undefined,
by environment variable "EDITOR".  /usr/bin/less will, if it knows how, 
even tell that editor to put your cursor at that exact spot you were
displaying in the "less" pager.

> my latest vim annoyance: vim really sucks at non-ASCII characters,
> it ends up not correctly drawing the screen or placing the cursor -
> e.g. the cursor is often shown on the screen at a location other than
> the active editing position ... ugh!

Yes, that's really annoying, and I'd actually forgotten it's something
nvi and original-vi get right.  

Other things to like about nvi:  It's light and fast to a degree that
makes light, fast vim look bloated by comparison, and normally exists as
a single, tiny, dynamically linked file.  Even statically compiled to be
utterly self-contained, it's still tiny.

Also, it's the absolute reference standard, replicating the documented
behaviour of original-vi with zero exceptions.  If you need that for
whatever reason, it's the right tool.  

The entire vi class of editors have the collective virtue of being a
familiar tool everywhere they exist, and have only minor differences
among them that are easily livable, which means they're a primary tool
for sysadmins:  No matter what gods-awful system I'm obliged to telnet,
rsh, or ssh to, if there's a vi-class editor, I automatically know how
to use it.

As to vim, two advantages stand out, at first thought:  (1) Infinite 
undo/redo.  With vim, I can backtrack all the way to the beginning of my
edit session with undo, undo... find the state of the document I want,
and work with that.  If I go too far, then redo, redo... reapplying my
work session, watching the re-evolving document again, and so on.  You
feel confident about cutting text and making other radical changes,
knowing you can back them out at any time, if necessary.

nvi / original-vi have one level of undo, which is useful, but means
that all of your edit history before the one immediately prior change is
discarded and cannot be retrieved.  If you hit undo, undo, undo out of
habit because you're accustomed to vim, you find to your dismay that
it's a one-step toggle:  undo, redo that undo, undo it again, etc.

(To see this effect in vim, run command "set cp" to set compatibility
mode, then note how the undo function immediately becomes somewhat
lobotomised.   As noted in many places, vim's "compatibility" mode does
not achieve absolutely 100% compatibility with original-vi as does nvi:
A few minor differences in behaviour persist.)

(2) Mode indicator.  vi-class editors being model, it's useful to know 
at any given moment whether you're in command mode or text-insertion 
mode.  Otherwise, the next few letters you type may not get inserted as
text, as you expect, but rather carried out as editing commands,
transforming your text in random ways, e.g., deletions, etc.  And, of
course, the combination of that syndrome with provision of only a single
level of undo can lead to disasterous results:  You end up saving

(The syndrome of accidentally typing commands rather than text,
especially when new to vi, is so proverbial that there's a standard joke
about vi's normal mode being "beep mode", where you attempt to type text
and vi rejects most of them, if you're lucky, as invalid commmands and 
beeps to complain at you.)

In vim, going into insert mode causes "-- INSERT --" to appear in the 
lower-left corner.  The similar overwrite mode causes "-- REPLACE --" 
to appear there.   If neither is showing, you're in command mode.
Instant enlightenment; problem solved.  No more "beep mode".

I haven't used the "elvis" implementation of vi in many years, but
remember one endearing aspect of the program:  If you logged out with an
edit session still open, next time you logged in, you had e-mail from

(So, the King's alive after all.  QED.)

More information about the sf-lug mailing list