Re: What is emacs architecture ?

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: frenzeee@gmail.com,
>     emacs-devel@gnu.org
> Date: Thu, 08 Jul 2010 17:22:20 +0900
> 
> Eli Zaretskii writes:
> 
>  > > http://www.xemacs.org/Documentation/21.5/html/internals.html
>  > > 
>  > > It's not intensively maintained, and obviously is going to differ from
>  > > GNU Emacs in many details.
>  > 
>  > In too many details, I'm afraid.
> 
> *At the level* we're talking about (UML diagrams!), it doesn't really
> matter if *redisplay* is *implemented* differently.  The problems
> encountered are the same, and it fits into the LISP read-eval-print
> loop in basically the same way.  (Ie, it's not actually a R-E-P loop,
> it's based on a GUI event loop with the R being "receive event" and P
> being "redisplay", and the E has to take account of being event-
> driven.)  I could be wrong, but it's my understanding that it is that
> kind of thing that the OP wants to get a handle on.

I'm not sure.  The general ideas are the same, that's true, but they
typically occupy only the first few sentences.  Once you get past
that, you get differences in names of structures, functions, and even
file names, let alone basic mechanisms that implement the same general
ideas.  So if one wants to look up the details in the code, one
cannot, and the detailed descriptions of the algorithms don't match
what Emacs does in many cases.

> Nor would it hurt the OP to see concepts that Emacs has rejected
> (extents and specifiers, for example), not to mention some of the
> things Emacs is currently in the process of thinking about adding
> (loadable modules) and even some of the things we've kinda horked and
> hopefully y'all will do better ("native" widgets).

I agree, but that should hardly be recommended as the first reading.
IMO, anyway.