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, which did abide in the land of
Spice Lisp, whose secrets were held by the Priests of the Carnegie
Mellon.  And Hemlock did prosper in the land of Spice Lisp, and did
grow beyond the narrow borders of PERQ.  For the land of Spice Lisp
became bound by marriage to the Common Lisp, and Hemlock did forsake
the language of MacLisp and its father EINE, and did sow new children
upon the ground of the Common Lisp of the Priests of Carnegie Mellon,
where its progeny would spread across Unix systems everywhere.  But
the Great Emacs of Saint IGNUcius would overtake the spread of
Hemlock, for Saint IGNUcius spread a gospel far sweeter to the ears of
the masses than that of the authors of the Common Lisp Standard.  Yea,
Hemlock, though it continue on even to this day amongst the
worshippers of the Priests of Carnegie Mellon, Hemlock did become
marginalized as it required a particular Common Lisp, whereas the
Great Emacs of Saint IGNUcius did spread its gospel in the language of
C, spoken by teeming masses of Unix hackers and other heathen.

'james

--

Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



Wed, 10 Mar 2004 08:31:37 GMT  
 ZWEI (Re: emacs rules and vi sucks)

Quote:
> [Lineagectomy]

=v= Where do FINE ("FINE Is Not EMACS") and BRIEF ("BRIEF Really
Isn't Even FINE") it into your list of begats?
    <_Jym_>


Wed, 10 Mar 2004 09:10:07 GMT  
 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.

__Jason



Fri, 12 Mar 2004 18:43:26 GMT  
 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)

Quote:

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

FWIW, Hemlock now seems to use the linked list of lines scheme.

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

Cadillac.

Tim



Sun, 14 Mar 2004 01:08:20 GMT  
 ZWEI (Re: emacs rules and vi sucks)
[ replying to comp.lang.lisp only
  http://world.std.com/~pitman/pfaq/cross-posting.html ]

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.

In my last days at Symbolics, worried that the hardware would go away, I
ported Zmacs to Symbolics Common Lisp (it still used the TV windows and
needed a CLIM port, but the data structures all ran in CL data structures;
I got rid of array leaders and special instance variables, something Moon
had previously claimed was too hard to do--I just love a challenge).  The
port is on some Symbolics backup tape somewhere, I suppose.  It had a few
glitches but basically worked; I had it on Select Epsilon so that I could
switch back and forth between it and regular Zmacs.  It wasn't part
of my tasked activity--just a little hack I was doing in my free time as a
"backup plan" for Symbolics because I didn't believe the company was on track
for survival and I wanted the tools to survive.  But I was laid off thenabouts
and the port went nowhere.

The ported code is called TRES (third in the series that begins with eine
and zwei, but since I'm a Spanish speaker not a German speaker, I switched
languages).  TRES stands for "TRES Replaces Eine's Successor".



Sun, 14 Mar 2004 03:33:56 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:
> In my last days at Symbolics, worried that the hardware would go
> away, I ported Zmacs to Symbolics Common Lisp (it still used the TV
> windows and needed a CLIM port, but the data structures all ran in
> CL data structures; I got rid of array leaders and special instance
> variables, something Moon had previously claimed was too hard to
> do--I just love a challenge).  The port is on some Symbolics backup
> tape somewhere, I suppose.  It had a few glitches but basically
> worked; I had it on Select Epsilon so that I could switch back and
> forth between it and regular Zmacs.  It wasn't part of my tasked
> activity--just a little hack I was doing in my free time as a
> "backup plan" for Symbolics because I didn't believe the company was
> on track for survival and I wanted the tools to survive.  But I was
> laid off thenabouts and the port went nowhere.

> The ported code is called TRES (third in the series that begins with
> eine and zwei, but since I'm a Spanish speaker not a German speaker,
> I switched languages).  TRES stands for "TRES Replaces Eine's
> Successor".

Damn, I'd love to get a copy of that.  Does Kalman or Dave Schmidt
read c.l.l?  Perhaps you should mention this on SLUG and see if they
remember what tape it might have ended up on.

Heck, some aspiring Lispm hacker could pick up from where you left off
and keep hacking it out until TRES was fully portable using CLIM.
Then you could run it in Allegro, for instance.  It would completely
kick ass over using [X]Emacs and an inferior Lisp process.

Honestly, if they finished the job Symbolics could even sell that.
And I wouldn't be surprised if people snapped it up.  Even with my
novice-level experience ZWEI seems a more powerful editor for Lisp
hacking because it's integrated with the running Lisp system.  But
then, to sell it they'd have to finish the rewrite.  And it's not like
Kalman doesn't have enough to do already.

(I think Symbolics needs more people.  But let's not start another
flamewar over that...)

Actually, that sounds like from what you describe even in its current
state it could be superior to ZWEI, at least in terms of
maintainability/debuggability.  I looked at the sources to ZWEI not
too long ago and ran away frightened.  The compiler looked easier to
understand... :-P

'james

--

Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



Sun, 14 Mar 2004 04:43:05 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:

> > In my last days at Symbolics, worried that the hardware would go
> > away, I ported Zmacs to Symbolics Common Lisp (it still used the TV
> > windows and needed a CLIM port, but the data structures all ran in
> > CL data structures; I got rid of array leaders and special instance
> > variables, something Moon had previously claimed was too hard to
> > do--I just love a challenge).  The port is on some Symbolics backup
> > tape somewhere, I suppose.  It had a few glitches but basically
> > worked; I had it on Select Epsilon so that I could switch back and
> > forth between it and regular Zmacs.  It wasn't part of my tasked
> > activity--just a little hack I was doing in my free time as a
> > "backup plan" for Symbolics because I didn't believe the company was
> > on track for survival and I wanted the tools to survive.  But I was
> > laid off thenabouts and the port went nowhere.

> > The ported code is called TRES (third in the series that begins with
> > eine and zwei, but since I'm a Spanish speaker not a German speaker,
> > I switched languages).  TRES stands for "TRES Replaces Eine's
> > Successor".

> Damn, I'd love to get a copy of that.  Does Kalman or Dave Schmidt
> read c.l.l?  Perhaps you should mention this on SLUG and see if they
> remember what tape it might have ended up on.

I've told Kalman it's there.  It was probably in my personal dir.  That
may have gone to a different backup tape than the "valuable assets".

Btw, recall that I mean "Symbolics Common Lisp" and not "ANSI Common Lisp".
So there would be a little more porting to do beyond that.  But I think
the remaining stuff was largely straightforward, and mostly had to do with
language extensions like all the extra search functions, etc.

Quote:
> Heck, some aspiring Lispm hacker could pick up from where you left off
> and keep hacking it out until TRES was fully portable using CLIM.
> Then you could run it in Allegro, for instance.  It would completely
> kick ass over using [X]Emacs and an inferior Lisp process.

I agree.  That's why I did it in the first place.  It was my personal
backup plan in case the VLM (er, Open Genera) didn't fly.

Quote:
> Honestly, if they finished the job Symbolics could even sell that.
> And I wouldn't be surprised if people snapped it up.  Even with my
> novice-level experience ZWEI seems a more powerful editor for Lisp
> hacking because it's integrated with the running Lisp system.

Yeah, I really miss the ability to stack up possibilities buffers and
to use Tags Multiple Query Replace From Buffer.

Quote:
> But then, to sell it they'd have to finish the rewrite.  And it's not like
> Kalman doesn't have enough to do already.

I'm sure some consultant would do it in trade for a share of the revenues.

Quote:
> (I think Symbolics needs more people.  But let's not start another
> flamewar over that...)

> Actually, that sounds like from what you describe even in its current
> state it could be superior to ZWEI, at least in terms of
> maintainability/debuggability.  I looked at the sources to ZWEI not
> too long ago and ran away frightened.  The compiler looked easier to
> understand... :-P

I can't speak to that.  I don't think it got any worse in the process but
I can't remember if it got better.  That wasn't a goal.  Getting it to run,
and getting past those "impossible" things was my goal.  I hate it when people
say things are impossible.  Especially on a Lisp Machine.


Sun, 14 Mar 2004 08:47:28 GMT  
 ZWEI (Re: emacs rules and vi sucks)

Quote:

>> Actually, that sounds like from what you describe even in its current
>> state it could be superior to ZWEI, at least in terms of
>> maintainability/debuggability.  I looked at the sources to ZWEI not
>> too long ago and ran away frightened.  The compiler looked easier to
>> understand... :-P

>I can't speak to that.  I don't think it got any worse in the process but
>I can't remember if it got better.  That wasn't a goal.  Getting it to run,
>and getting past those "impossible" things was my goal.  I hate it when people
>say things are impossible.  Especially on a Lisp Machine.

You guys sounds like astronauts in the NASA of the 1960s.

Sashank.

PS: That was a complement.



Sun, 14 Mar 2004 10:39:19 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)

Quote:



>>> Actually, that sounds like from what you describe even in its
>>> current state it could be superior to ZWEI, at least in terms of
>>> maintainability/debuggability.  I looked at the sources to ZWEI
>>> not too long ago and ran away frightened.  The compiler looked
>>> easier to understand... :-P
>>I can't speak to that.  I don't think it got any worse in the
>>process but I can't remember if it got better.  That wasn't a goal.
>>Getting it to run, and getting past those "impossible" things was my
>>goal.  I hate it when people say things are impossible.  Especially
>>on a Lisp Machine.
> You guys sounds like astronauts in the NASA of the 1960s.

> Sashank.

> PS: That was a complement.

[Unfortunately, these days, NASA getting something into the sky
requires that the weight of the stack documentation exceeds the weight
of the fuel required to put the device into orbit.  And working on it
requires reading the documentation first...]
--

http://www.cbbrowne.com/info/wp.html
Who  needs fault-tolerant  computers when  there's obviously  an ample
market of fault-tolerant users?


Sun, 14 Mar 2004 12:36:12 GMT  
 ZWEI (Re: emacs rules and vi sucks)

Quote:

> > Damn, I'd love to get a copy of that.  Does Kalman or Dave Schmidt
> > read c.l.l?  Perhaps you should mention this on SLUG and see if they
> > remember what tape it might have ended up on.

> I've told Kalman it's there.  It was probably in my personal dir.  That
> may have gone to a different backup tape than the "valuable assets".

Well, if I was in your shoes I'd offer to come over and visit one
weekend to go hunting through the tapes yourself.  But that's me.

Quote:
> Btw, recall that I mean "Symbolics Common Lisp" and not "ANSI Common Lisp".
> So there would be a little more porting to do beyond that.  But I think
> the remaining stuff was largely straightforward, and mostly had to do with
> language extensions like all the extra search functions, etc.

Ahh, just replace all the greek and math symbols and strip out the
font stuff and it should work fine, as long as you didn't use any of
that new-fangled CLOS stuff. ;-)

Quote:
> > Heck, some aspiring Lispm hacker could pick up from where you left off
> > and keep hacking it out until TRES was fully portable using CLIM.
> > Then you could run it in Allegro, for instance.  It would completely
> > kick ass over using [X]Emacs and an inferior Lisp process.

> I agree.  That's why I did it in the first place.  It was my personal
> backup plan in case the VLM (er, Open Genera) didn't fly.

I was telling someone about the VLM today...  About how many lines of Alpha
assembler is it, do you remember?  A lot, I know that.  I guess it did
fly, after a fashion.  But it didn't fix the bad management.  Oh well.

Quote:
> > Honestly, if they finished the job Symbolics could even sell that.
> > And I wouldn't be surprised if people snapped it up.  Even with my
> > novice-level experience ZWEI seems a more powerful editor for Lisp
> > hacking because it's integrated with the running Lisp system.

> Yeah, I really miss the ability to stack up possibilities buffers and
> to use Tags Multiple Query Replace From Buffer.

I miss how M-. worked on *anything*.  And DocEx.  I *really* *really*
*really* miss having DocEx.  Sigh.

Quote:
> > But then, to sell it they'd have to finish the rewrite.  And it's not like
> > Kalman doesn't have enough to do already.

> I'm sure some consultant would do it in trade for a share of the revenues.

Oh yeah, certainly.  I can hear people volunteering already... :-)

Quote:
> > Actually, that sounds like from what you describe even in its current
> > state it could be superior to ZWEI, at least in terms of
> > maintainability/debuggability.  I looked at the sources to ZWEI not
> > too long ago and ran away frightened.  The compiler looked easier to
> > understand... :-P

> I can't speak to that.  I don't think it got any worse in the
> process but I can't remember if it got better.  That wasn't a goal.

Well, it's not in C, so that's a big step in the right direction
anyway.  If it was in CL then the process of making it easier to
maintain could be done gradually.

Quote:
> Getting it to run, and getting past those "impossible" things was my
> goal.  I hate it when people say things are impossible.  Especially
> on a Lisp Machine.

Nothing is impossible on a Lisp Machine.  Except maybe ... uhh
... getting the damned tape drive to work.  They love eating tapes!

'james

--

Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.



Sun, 14 Mar 2004 15:20:11 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 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