From: Nikolai Weibull <ruby-talk@...>
Date: 2004-08-17T05:39:06+09:00
Subject: Re: About ruvi

* Hal Fulton <hal9000@hypermetrics.com> [Aug 16, 2004 21:20]:
> But to someone who only uses 1% of vim's features, ruvi will
> indeed be a clone (assuming it's the same 1%).

I feel it is time for me to say something on this thread.
ruvi (crude) family tree:

	ed->vi->vim->ruvi

And remember, I said crude, I do not need any smug responses discussing
Qed's involvement and so on, I bet I know more than most on the subject.

(So much for not being smug I guess)

So, why did I bring up this family tree?  Well, a family tree is kind of
like inheritance in object-oriented programming, right?  And with
inheritance in OO comes a lot of niceties, but when it comes to
inheritance in programs like the line of editors above, you are bound to
wind up with a lot of the problems humans and other animals experience
when bred in a too small gene-pool.  You get stuck in a certain mode of
thinking, which was not really yours to begin with, and you can not
easily get out of it.  You're stuck with a lot of cruft from past
generations and new features will depend on cooperating correctly with
the old.

I'm not saying this is wrong-I certainly love having Vim around-but
simply "cloning" 30-40 year old technology will not get you the best end
results.

So, before we all start pressing Alexander for Vim features, just
consider that neither Vim, nor ruvi as a Vim "clone", is a panacea.

As some might remember, about a year ago I started reasoning about and
developing (mostly reasoning to be honest) my master's thesis, which is
centered around regular expressions and text editors.  I'm trying to
figure out ways to make regular expressions-and other formal languages
such as regular relations and context-free grammars-much more pervasive
the editing process.

s// and g// are great commands, but they have limitations that are
inherent from the way UNIX was developed.  The UNIX philosophy has
always been "everything is a stream of bytes" (well, it's one of the
guiding philosophies anyway)-which certainly causes problems with
Unicode, as this isn't true anymore (well, there's always UTF-8, but I
have a feeling this will a temporary solution to a bigger problem (don't
get me wrong, I like UTF-8 (and nested parentheses)))-yet most tools
deal with streams as records separated by newlines (\n, 0x0a, ^@, ...).
(Again, problems with Unicode as there are now a lot more newlines to
worry about).  This restriction certainly limits the possible
applications of commands such as s// and g// and this is what I intend
to remedy.  The text editor sam(1) has certainly been a great
inspiration to me and when I read Rob Pike's paper on it I knew I could
not continue using Vim without at least trying to experiment with the
ideas put forth in that paper.

So, in conclusion, limiting oneself to emulate old software has a
tendency to also limit possibilities for implementing new ideas as well.
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}