> gaynor> vi can't handle arbitrary-lengthed lines? Hee hee, and people wonder
> gaynor> that users of real text editors bust vi's chops so much?
> Er, "real text editors" as in "editors capable of editing any file which has a
> text representation".
Fine, I'll take an intel hex dump, split it, edit that, then concatenate it
and run undump on it. The hex dump is the text representation.
Quote:> peter> Emacs won't run on a PDP-11? And people wonder why real users without
> peter> unlimited hardware budgets dump on Emacs so much?
> The truth hurts. GNU Emacs should have been written in a machine precision
> independent fashion.
Machine address-space independent, too.
Quote:> This portion of my discussion was neither highly opinionated nor flamable.
> There is simply not a lot of leeway in the definition of `text'. Distance
> between eol indicators is irrelevant.
Sure there is. There are more definitions of what constitutes "text" than
you can shake a stick at. One of them is "the executable code segment of
a UNIX program".
The common usage of "text" refers to human readable data organised as a
collection of strings of ascii characters (lines). Tools used to manipulate
these strings frequently place limits on their length.
VI is easily applicable to a smaller set of problems than Emacs, I will
freely admit that, but it requires far fewer resources and is much more
And Emacs has its own design problems. We haven't had a good flame war over
Emacs and VM (the buffer gap method tends to thrash VM when jumping around
You seem to have this basic assumption that Emacs is clearly a win over vi
in all circumstances. I contend that this is only true in an extremely
resource-rich environment... and even then start-up time is high enough
that you need to keep it around most of the time even when you're not using
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"