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

[Christopher Dimech]

> Sent: Thursday, September 14, 2023 at 8:52 AM
> From: "Lynn Winebarger" <owinebar@gmail.com>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs design and architecture (was: Shrinking the C core)
>
> 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.

One thing that needs rewriting is texinfo to use the latest functionalities 
that are provided by the LaTeX3 Project (https://www.latex-project.org/latex3/)

Today we continue to be restricted by what the TeX Core Engine can do.
We are continuing to work with the pre-1983 version before Leslie Lamport 
developed LaTeX, a higher-level markup language built on top of TeX. 

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