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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: owinebar@gmail.com, emacs-devel@gnu.org
> Date: Sat, 16 Sep 2023 20:45:00 -0400
> 
>   >   . "buffer with gap" for storing buffer text
>   >   . "mark and sweep" GC
>   >   . basic single-threaded MVC architecture
>   >   . display engine design around the rectangular canvas model and
>   >     on-the-fly layout decisions
> 
> These are internal design decisions.
> The last one does relate to some user-level features
> such as data in the buffer.  The first three don't.
> 
> So I don't see these as being related to simplicity
> that benefits the users.

That is true, by and large, but the simplicity that benefits users is
not the only issue at stake.  There's also the issue of being capable
of performing complex computations efficiently, i.e. quickly and
without locking up Emacs; multi-threading and a more modern GC could
give us at least some of that.  Being able to use multiple execution
units in parallel is also the main (perhaps the only) path towards
letting Emacs make good use of modern system architectures.

> A more complex and powerful data structure in the buffer is something
> I would like to see.  I would like it to enable TeX-style formatting
> of text for display.

In off-line discussions with Stefan Monnier, we both arrived at the
conclusion that some basic limitations of the current display engine
cannot be lifted without redesigning how buffer text is stored and
accessed.  So yes, buffer's data structures are an important factor in
what features we could introduce in the future, in particular related
to sophisticated and efficient redisplay.

> However, finding a good design for this will be a hard job, I think.
> We would want it to facilitate redisplay and also be easy for editing.
> It needs to support editing primitives of the traditional Emacs kind,
> which treat text as a sequence somehow (even if not the same as now),
> and editing primitives that operate on the structure and make them
> convenient.

Right.

> All four of those directions are basically independent.
> Any one could be done with or without the others.

They are not completely independent, no.  They _could_ be independent
if the design of each direction took into consideration the possible
designs of the other directions up front, so as not to preclude
developments of those other directions or make them too hard.  And
doing some changes in only one direction could mean unnecessary work.
For example, any significant changes in the display engine without
simultaneous changes in buffer text access would mean either writing
code that will be tossed in the future, or coming up with some
abstraction that could be easily changed when buffer text access
changes; both mean non-trivial extra efforts.  Likewise, redesigning
buffer text storage and access must have the display engine needs
effect the main design decisions, even though redisplay is not being
reimplemented at the same time.