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

[Lynn Winebarger]

On Thu, Sep 14, 2023 at 1:58 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

That makes sense.  The term "text-processing system" just evoked
something non-interactive to me, like sed, awk, tex, etc.


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

Could this be subdivided into two design issues:
* Decoupling the display (or view?) from the buffer being displayed
* Providing a more flexible canvas

So under the first would be doing something like interposing objects
representing syntactic entities in between the display and the buffer,
so the user could interact directly with those objects, as opposed to
having those objects attached to text intervals or overlays, and
having the interaction backed into.

For the other, it sounds like you'd like to have more GUI primitive
type operations available on the canvas directly, without having to
use explicit GUI objects like child frames.  But I have no idea how
far you would want to go in replicating GUI functions in the emacs
graphics display.  It's just not my area.  I'll go out on a limb and
say that to be interesting, the additional flexibility in the canvas
would have to be programmable from emacs lisp, and that would require
emacs lisp to be much faster than it is now, and essentially
parallelizable in a way that it is not now?  Those are things I can
work on, though they are not short term projects.



Lynn