ZWEI (Re: emacs rules and vi sucks) 
Author Message
 ZWEI (Re: emacs rules and vi sucks)


Quote:




> > > | 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.



Sat, 13 Mar 2004 20:52:54 GMT  
 ZWEI (Re: emacs rules and vi sucks)

Quote:

>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).

Quote:
>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?

--

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.



Sun, 14 Mar 2004 00:18:40 GMT  
 ZWEI (Re: emacs rules and vi sucks)

    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



Sun, 14 Mar 2004 04:16:53 GMT  
 ZWEI (Re: emacs rules and vi sucks)


Quote:

>    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?

Slow as molasses.  Moving the mouse over a Lisp Listener causes the CPU to
spin heavily.

--

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.



Sun, 14 Mar 2004 04:48:20 GMT  
 ZWEI (Re: emacs rules and vi sucks)


Quote:


> >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?

Quote:
> >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.


Sun, 14 Mar 2004 10:44:34 GMT  
 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.

Quote:






> > > > | 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.



Sun, 14 Mar 2004 17:21:46 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. ZWEI (Re: emacs rules and vi sucks)

2. ZWEI mode in Emacs

3. ADA SUCKS, C/C++/JAVA RULES!!!!

4. Programming language sucks-rules-o-meter

5. emacs gnus scoring rule for c.l.s mailpost-gateway sp*m

6. vi or emacs for editing Python on Linux?

7. Customizing Emacs to look like VI (yes!)

8. Send command to emacs/vi possible?

9. CFP: RULE'02 - PLI-Workshop on Rule-Based Programming

10. CFP: RULE 2001 (2nd Int'l Workshop on Rule-based Programming)

11. CFP: RULE'02 - PLI-Workshop on Rule-Based Programming

 

 
Powered by phpBB® Forum Software