I started to reply at length to the many misstatements in your
message.  I don't really have a problem with your excitement about
Emacs.  I use Emacs a lot.  I have for over 20 years.  I'm typing to
it now.  BUT to the extent that you try to claim it replicates Genera,
you're both kidding yourself (which I don't really care about one way
or another) and engaging in historical revisionism (which does trouble
me and is the reason I'm responding here).

The value in Genera's Dynamic Windows is NOT about "completion" it's
about object-oriented connected-ness of the entire system.  You aren't
clicking on the "name" in dynamic windows.  You are clicking on the EQ
object.  This means you can, for example, mouse an instance of
something and get that instance as an object to inspect and
manipulate.  Emacs has NO basis for equivalent stuff.  None.  If
you've seen Genera only through screen shots, you could never imagine.
It's like trying to explain someone whose only seen streams of text
what an object pointer is.

Last night on my Lisp Machine I was frustrated by the absence of NT
file support.  I had no idea how file support was implemented, but I had
a general working understanding of how the Lisp Machine was organized,
and within a small number of hours I had learned about how to extend the
operating system to talk to NT over TCP and implemented a new set of classes
so that I could transparently talk to my NT box over my local ethernet.
A lot of my ability to do this was enabled by the ability to point and click
on objects in order to debug them and inspect them without any fear or
confusion about whether I was using the right sources, the right packages,
etc.

I cannot by any stretch of the imagination sit down at Emacs and do
the equivalent thing.  I can't learn about even how to extend Emacs
itself in so short a time, much less use Emacs to help me learn about
Windows NT or Unix or whatever.  Sure, Emacs has some
self-documentation.  Sure, the sources are there.  But for example,
there's no assurance when I read in a source file that it's the same
source file that I loaded.  The lisp machine keeps meticulous records
not only of which source files are loaded and from where but which
functions have been patched by which files.  That means I can't make a
mistake and use the wrong tags file or the wrong version of files
backing up a tags file.  I was confused by the behavior of something
that and I looked at its source, it correctly told me about the patch
file that had redefined the function rather than just leading me to
believe that the system source was correct.  There are myriad subtle
ways in which Emacs is only a pale shadow of Zmacs.

Not resources.  Objects.  All objects.  Not just the heavyweight ones.
Lists.  Integers.  I somehow don't believe you when you say this is the
same as what Genera does.

The usual thing DW enables is the debugging of things that the
person did NOT make part of the standard interface.  Pointing to a UI
tool and saying it allows you to plan for structured debugging of
something is missing the point.

Or maybe you're saying that Garnet allows me to cross the boundary into
the internals of systems.  Maybe I'm missing out.

When you can make the claim that if you teach me a few paragraphs
worth of stuff, I will have all of the information I need in order to
bootstrap myself into a complete understanding of the entire operating
system and all of its conventions, I'll believe you Garnet and X are
as powerful as Genera and Dynamic Windows.  Until then, I'll continue
to believe they are different.  Incidentally, I'm dying to know that
there is a tool that will do all that Genera could do only for stock
hardware becuase the stack of books I need to buy in order to be
equivalently competent with other systems is daunting and I could
really do with the savings in time, energy, and money of learning things
about standard systems in the way I've been doing...

I don't even find Emacs itself to be equivalently self-documenting and
easy to get around in, much less the many systems that Emacs touches.

Look, I used to literally sit around in my office at MIT years ago and
fuss at people who said Lisp Machines were everything.  (I used and liked
Lisp Machines but I myself didn't think they were what they were because
of the hardware--they were what they were because of the software and
the ideas behind them.)  I used to ask people "What's an impossible thing
to do?  I'm looking for something to do this afternoon in Teco that people
say can only do on Lisp Machines."  People said Zmail.  I wrote the
approximate equivalent in Teco--filters, and all that.  They wanted a
filter menu.  I wrote that in Teco.  They wanted mouse handling.  (That
was tough because PDP10's didn't have mice, but I used my imagination a
little and arranged a mouse protocol from Lisp Machines so you could telnet
to the teco-based Emacs and click on my filter menus.)  They wanted
Zmail init files.  I wrote a Lisp compiler in Teco so that I could use
people's Zmail init files unmodified.  It was about 20K words of Teco
code, btw. Code was smaller back then... sigh.

Anyway, I *know* what it is to look at functionality and duplicate it
elsewhere.  It CAN be done.  I am not saying it can't.  What I'm
saying is that it has not been done, and it's a crying shame.  Few
people even know there ever WAS a lisp machine, and those who do are
mostly not rich enough personally to invest the time to duplicate what
was there.  Many people spent a big chunk of their lives investing in this
dream and it didn't pan out quite as we wish.  Ok.  Sometimes other
events win out--not always  even for the right reasons.  Or at least for
the reasons you wish.  But don't add insult to injury to say that the
losers in battles such as these had nothing to offer.

Common Lisp beat out Interlisp, and maybe for good reasons but it doesn't
mean Interlisp had nothing to offer--some very good ideas got lost in the
shuffle and I don't pretend that Common Lisp just obviously had a better
way.  Java is going to beat out Smalltalk perhaps, but that doesn't mean
Java is better than Smalltalk.  We owe it to the losers in these little
skirmishes to make sure that, if nothing else, the good ideas are not lost
along with the framework.  And we do not accomplish that by defining
that there was nothing lost.  That's both callous to those who worked
hard on these other things and short-sighted to the future, which might one
day care about the things that got lost.

There are still Lisp Machines around.  If you want to opine on them
with authority, get one and use it.  There is no substitute for first-hand
data in situations like this.

Here are a few, not intended to be complete, but to give you a spirit
of the degre of "precision" in Zmacs commands that distinguish them from
Emacs commands:

 * Tags Multiple Query Replace From Buffer

   This is an extension to Tags Multiple Query Replace (which does a
   multiple-strings-at-once Query Replace over a Tags Table; and,
   incidentally, the Tags Tables don't have to be files--the Lisp
   Machine just makes them up on the fly from spaces of buffers, from
   system definitions, etc. on user request).  It allows you to put
   pairs of elements and their replacements in a buffer and have
   all replaced in parallel.

   As with all operations of this kind (including Tags operations and
   other mapping operations like "Edit Compiler Warnings"), this creates
   a "possibilities buffer" which is a physical manifestation of keeping
   your finger on where you were in the middle of a complex operation
   so that if you see something else you want to do while you are
   doing the replacement, you can suspend the operation and resume it
   later perhaps after doing other replacements or edits.  When editing
   the ANSI CL spec, something I refused to do on anything but a Lisp
   Machine, I often had dozens of these buffers stacked up in simultaneous
   use and was successfully able to resume them to make sure all completed
   while allowing the system to accomodate my "focus".

 * Source Compare

   This command allows you to run a source comparision program (which
   itself is just presentationally way better than Unix diff or
   emacs compare-windows).  There was a public version of a source
   comparison program written by someone a while back that is as good
   but is in CL and isn't integrated into Emacs.  Alas.  But in addition
   to the presentational issues, which are comparatively minor, the real
   feature was how this could be called.  It prompts for two things
   describing what to compare, including "buffer", "file", "region",
   "definition", "top of kill ring" and "second in kill ring".  you type
   a single character (B/F/R/D/c-Y/m-Y) for each such prompt.  It's
   completely essential for comparing files.  What I can't comprehend
   is why no one thinks this is essential in a non-versioned file system.
   It's important enough in a versioned file system but in a non-versioned
   system one is always finding "probable copies" of files all over the place
   and trying to understand the differences.  Ready access to program
   controlled source compare is central to everything I do and basically
   wholly absent on stock hardware.  Another example is when you are saving
   a file on the lisp machine and you find it's been written by someone else;
   in emacs the query just tells you of a problem--in zmacs it offers to
   compare the files before making you decide whether to continue saving.

   It's not the feature itself, though that's important, but
   it's the attention to detail at this fine-grained level throughout the
   system which is why the lisp machine is so fondly remembered.

And that's my overall point.  It's not just about what's missing.
It's about the lack of interest in those who have created Emacs in
supporting those other things.  I still just use my Lisp Machine.
It's right here next to my PC, and on a regular basis I just move to
the other chair and edit in Zmacs.  6 years after heavy-duty
development ceased on Zmacs, it still whomps the competition and makes
me not care that processor speeds have gone up a zillionfold in the
meantime.  Others will tell you the same.

I WISH I could use features like that on a fast processor.  that would
be great.  But it isn't likely to happen soon.

You can say the burden is on us old-timers to tell you what's missing or
we shouldn't be whining.  But I don't see it that way.  I see the burden is
on the victors, who have the resources  and who claim their way is better,
to show us that they won for good reason.  We did our part for the cause.
We may or may not continue to try to do things to assure the ideas aren't
lost.

I spend a lot of my time trying to make sure old ideas make it onto
the books and don't get lost.  But I'm just one person.  It takes more
than one person.  And the task does not begin by dismissing the need
to do the job.