[Prev][Next][Index][Thread]
Re: ZWEI (Re: emacs rules and vi sucks)
I also think it should be said the emacs is what, 20 years old or
something like that...
Memory and speed were extremely important back then. It's much easier to
program now days with virtually unlimited address spaces and gigahertz
processors. You can design for elegance and rarely compromise for
performance.
> "Jason Trenouth" <jason@harlequin.com> wrote in message
> news:gb3uqtgqo43o9v8aghfemk124lubg8a5qj@4ax.com...
> > On 21 Sep 2001 16:31:37 -0800, james@unlambda.com (James A. Crippen)
> wrote:
> >
> > > Ole Aamot <oka@ping.uio.no> writes:
> > >
> > > > * james@unlambda.com (James A. Crippen)
> > > > | I wonder if Saint IGNUcius approves of using ZWEI...
> > > >
> > > > I used to believe that there could only be EIN Emacs.
> > > > But I do not believe in that ZWEI was eine initially.
> > >
> > > And TECO Emacs begat EINE, and EINE begat ZWEI, and ZWEI begat Zmacs.
> > > Thus was the ancestry of the Lisp Machine editor begun. And the
> > > bastard child of EINE was Hemlock, ...
> >
> > And yet in the darkness Hemlock did begat the LispWorks Editor.
> >
>
> Here's a little more historical detail, for anyone interested.
>
> gnuemacs is quite different from the Eine/Zwei family of
> editors, in that it uses the "bigline" structure to model the
> contents of its buffers. Hemlock and the LW editor also
> use this representation. Buffer pointers (BPs) are then simply
> integers that point into the bigline. This can be a very space-
> efficient structure, but the downside is that it is very hard to
> have any sort of polymorphic "line" object. This makes it
> much tougher to do things like graphics; a friend from Lucid
> told me that Jamie Zawinski, a formidable hacker, spent about
> a year a year wrestling with gnuemacs before he could make
> it general enough to do the sorts of things he got Xemacs to do.
>
> Zwei models buffers as linked lists of line objects, and BPs
> are a pair {line,index}. This makes it easier to do some
> clever stuff in Zwei, but IIRC lines in Zwei are structures,
> not classes, so it turned out that we had to wrestle quite a
> bit with Zwei to get display of multiple fonts and graphics
> to work (on the order of many weeks).
>
> The editor for FunO's Dylan product -- Deuce -- is the
> next generation of Zwei in many ways. It has first class
> polymorphic lines, first class BPs, and introduces the idea
> first class "source containers" and "source sections". A
> buffer is then dynamically composed of "section nodes".
> This extra generality costs in space (it takes about 2 bytes of
> storage for every byte in a source file, whereas gnuemacs
> and the LW editor takes about 1 byte), and it costs a little
> in performance, but in return it's much easier to build some
> cool features:
> - Multiple fonts and colors fall right out (it took me about
> 1 day to get this working, and most of the work for fonts
> was because FunO Dylan doesn't have built-in support for
> "rich characters", so I had to roll my own).
> - Graphics display falls right out (e.g., the display of a buffer
> can show lines that separate sections, and there is a column
> of icons that show where breakpoints are set, where there
> are compiler warnings, etc. Doing both these things took
> less than 1 day, but a comparable feature in Zwei took a
> week. I wonder how long it took to do the icons in Lucid's
> C/C++ environment, whose name I can't recall.)
> - "Composite buffers" (buffers built by generating functions
> such as "callers of 'foo'" or "subclasses of 'window') fall right
> out of this design, and again, it took less than a day to do this.
> It took a very talented hacker more than a month to build a
> comparable (but non-extensible) version in Zwei for an in-house
> VC system, and it never really worked right.
> Of course, the Deuce design was driven by knowing about the
> sorts of things that gnuemacs and Zwei didn't get right (*). It's so
> much easier to stand on other people shoulders...
>
> (*) By "didn't get right" I really mean that gnuemacs and Zwei had
> design goals different from Deuce, and in fact, they both had initial
> design goals that were different from where they ended up.
>
>
>
>
References: