[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: Emacs design and architecture (was: Shrinking the C core)
Date: Thu, 14 Sep 2023 19:52:23 +0300

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Thu, 14 Sep 2023 12:30:27 -0400
> Cc: rms@gnu.org, emacs-devel@gnu.org
> > 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.

How is this different from display properties, overlays and images,
which we already have?

The problem is not to display objects that don't come from buffer
text: we already have that.  The problem is that our layout engine
cannot superimpose one object on top of the other, and the geometry of
the layout is hard-coded as "glyph rows".  IOW, it's a pure display
layout problem, not a problem with decoupling display from buffers.

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

We cannot draw on the canvas directly without making the display
engine aware of what we are drawing and where, because the display
engine is responsible for updating the display when something changes.
So what we need is to be able to place a glyph using arbitrary 3D
coordinates (the 3rd coordinate for overlaying stuff on top of what's
already displayed), instead of having to work with rows of glyphs.

Again, studying what others do in this area would be useful, I think.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]