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

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Wed, 13 Sep 2023 16:52:15 -0400
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> I think I was more interested in why you said it would be a
> "text-processing system" rather than an editor or even IDE

Emacs is more than an editor and an IDE.  Gnus (and other MUAs we have
in Emacs) is neither, and neither is Org or ERC or any number of other
Emacs features.

> >   . display engine design around the rectangular canvas model and

> I don't know what the alternative is, exactly.

Finding that out is part of the job.  It's quite likely (I hope) that
the relevant technology already exists, and we don't need to invent
it.

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

You misunderstood what I meant by "rectangular canvas model", I think.
In Emacs, every screen line is represented as a "glyph row", a linear
array of glyphs, and the window's display is represented as a liner
array of glyph rows.  This is why we cannot (easily) have an image
that spans more than one screen line, and why we cannot have display
elements (like images or text boxes) overlaid on top of buffer text.