Re: Emacs design and architecture (was: Shrinking the C core)

[Lynn Winebarger <owinebar@gmail.com>]

On Tue, Sep 12, 2023 at 9:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Tue, 12 Sep 2023 07:31:35 -0400
> > Cc: Richard Stallman <rms@gnu.org>, incal@dataswamp.org, emacs-devel <emacs-devel@gnu.org>
> >
> >  If Emacs will ever be "rewritten", it will not be Emacs, but a
> >  text-processing system with a very different architecture and design,
> >  which will take from the Emacs experience the lessons we learned and
> >  implement them differently, to produce a system whose starting point
> >  is closer to the needs of today's users and whose main technologies
> >  are more modern from the get-go.
> >
> > It sounds like you have some specific ideas.  I wouldn't mind hearing them at more length.
>
> They are all well known.  And they aren't ideas, just main design
> features of Emacs which we found restrictive in some aspects:

I think I was more interested in why you said it would be a
"text-processing system" rather than an editor or even IDE, what you
perceive as the unmet needs of today's users, and what modern
technologies you think are applicable to the problem.  I'm not an
expert in the display or text-encoding aspects of what Emacs does, so
I really don't know what you have in mind.  I do have some ideas in
terms of extension language implementation.  There are definitely some
techniques used in implementing V8 that could be brought over.

>   . "buffer with gap" for storing buffer text
>   . "mark and sweep" GC
>   . basic single-threaded MVC architecture

These three I have some ideas on, which I've outlined previously,
using git and other distributed VC techniques as inspiration.
However, those are longer term goals.  For my first effort, I'm
focusing on some low hanging fruit for creating tree-sitter parser
tables and lexers in elisp and being able to create them dynamically,
with some supporting technology that can also be applied to more
generic dumping and garbage collection.

>   . display engine design around the rectangular canvas model and
I don't know what the alternative is, exactly.  VS Code and other IDEs
I've used have more varied decorative elements and containers, but
text is still pretty much presented in rectangular containers with
sides parallel to the GUI window (frame in Emacs terms).

>     on-the-fly layout decisions
>
> > My understanding is the design is deliberately kept simple (or "simple") to make it accessible to
> > more programmers.
>
> Richard will tell, but I don't think this goal was ever of high
> priority, back when Emacs was still being designed.
>
> > Instead of discussing porting emacs to CL,  why don't people work on porting the compiler
> > techniques used in CL to emacs?
>
> Well, native-compilation is one step in that direction.  We've been
> discussing something like that for many years, and we even tried a
> couple of approaches (which didn't work).  Native compilation is the
> first successful experiment in that direction.  Working on making the
> native code more efficient is definitely encouraged.

It's on my agenda.  Not native code, per se, though.  I think there
are some changes to the VM design (that the native code has to be
consistent with) that are required.  The strict stack discipline is
inherently inefficient, and since not every function parameter is
dynamically scoped, there are plenty of opportunities to optimize away
unnecessary function call overhead.  That and more efficient GC design
go hand in hand.

Lynn