ZWEI (Re: emacs rules and vi sucks)
Scott McKay
"Jason Trenouth" <ja...@harlequin.com> wrote in message
news:gb3uqtgqo43o9v8ag...@4ax.com...
> On 21 Sep 2001 16:31:37 -0800, ja...@unlambda.com (James A. Crippen)
wrote:
>
> > Ole Aamot <o...@ping.uio.no> writes:
> >
> > > * ja...@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.
Barry Margolin
Scott McKay <s...@mediaone.net> wrote:
>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).
Of course, the most likely reason for this, I think, is that ZWEI was first
implemented *before* Flavors, so there was no class system available. Most
of the higher-level data structures (e.g. buffers and windows) were later
Flavorized, but I guess no one felt that it was critical enough to redesign
the low-level lines and buffer pointers. Perhaps because these objects are
used in so many inner loops there might have been a worry about the
performance impact (we all remember what things were like when Dynamic
Windows first came out and suddenly the whole UI became a conglomeration of
instances with mouse sensitivity).
>The editor for FunO's Dylan product -- Deuce -- is the
>next generation of Zwei in many ways.
I'm just curious: is Deuce a self-referential acronym, and if so what does
it stand for?
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Raymond Toy
Barry> performance impact (we all remember what things were like when Dynamic
Barry> Windows first came out and suddenly the whole UI became a conglomeration of
Barry> instances with mouse sensitivity).
Not me. Before my (Lisp) time. What was it like?
Ray
Barry Margolin
Slow as molasses. Moving the mouse over a Lisp Listener causes the CPU to
spin heavily.
Scott McKay
"Barry Margolin" <bar...@genuity.net> wrote in message
news:A72s7.2$5w4.728@burlma1-snr2...
> In article <G6%r7.26054$vq.54...@typhoon.ne.mediaone.net>,
> Scott McKay <s...@mediaone.net> wrote:
> >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).
>
> Of course, the most likely reason for this, I think, is that ZWEI was
first
> implemented *before* Flavors, so there was no class system available.
Most
> of the higher-level data structures (e.g. buffers and windows) were later
> Flavorized, but I guess no one felt that it was critical enough to
redesign
> the low-level lines and buffer pointers. Perhaps because these objects
are
> used in so many inner loops there might have been a worry about the
> performance impact (we all remember what things were like when Dynamic
> Windows first came out and suddenly the whole UI became a conglomeration
of
> instances with mouse sensitivity).
Yes, definitely. Remember ":ordered-instance-variables", which
was a hack to be able to access Flavor instance variables at
roughly the same speed as structure slots?
> >The editor for FunO's Dylan product -- Deuce -- is the
> >next generation of Zwei in many ways.
>
> I'm just curious: is Deuce a self-referential acronym, and if so what does
> it stand for?
>
Actually, I called it Deuce as a conscious homage to Zwei, then
force-fit an acronym: Dylan Environment Universal Code Editor.
"Universal" was an adjective that I and some other high-school
hacker friends always seemed to self-importantly apply to our
(in retrospect) silly programs, so it seemed like a good way to
poke fun at myself.
r...@americom.com
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.