Re: Emacs and Gnome Canvas

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 11:29:29 +0200
> From: Jan Djärv <address@hidden>
> CC: address@hidden, address@hidden
> 
> > But the inserted character could be in the portion that is not
> > displayed at all, in which case it does not "require redisplay".  Who
> > should decide whether redisplay is necessary?  If that's Emacs, then
> > it should know a lot about the display layout.  If its the Canvas,
> > then it should know a lot about what portions of the buffer text are
> > on the screen.
> 
> You probably have your text in an CanvasItem that has a GtkTextBuffer.  When 
> a 
> character is inserted, you insert in to the GtkTextBuffer.  The redisplay 
> part 
> is then handeled internally between GtkTextBuffer, GnomeCanvas(Rich)TextItem 
> and GnomeCanvas.
> 
> As I said, it probably relies on having all text in the GtkTextBuffer.

But GtkTextBuffer needs text with attributes, right?  Currently, we
compute these attributes as part of redisplay, and only for the
displayed portion of the text.  Using GtkTextBuffer, it seems like we
will need to have a part (or an equivalent) of that redisplay code,
which would need to recompute the attributes for _all_ of the text,
after each modification of buffer text?  How can this be fast enough?
E.g., what if I'm viewing a large log file with non-trivial
fontification and clickable parts?

And what about redisplay optimizations?  For example, we now have a
special method that updates a window if the only change is that point
moved.  We don't care _why_ it moved -- there could be any number of
input events that cause this.  However, _determining_ that only point
moved is a non-trivial job, which examines about a dozen conditions on
some internal variables and flags.  Then there's another non-trivial
job: where on screen to move the cursor given the position of point.

If the communications with the Canvas is by means of a GtkTextBuffer,
how can these chores be done?  Won't we need to regenerate the
GtkTextBuffer, or at least its large parts, even when the only change
is point movement?

> >>>   How about an arbitrary mouse move?
> >>
> >> If it resulted in a different highlightning of a link, yes.
> >
> > Again, how to know that?  Note that some mouse movements perform
> > complex operations on Emacs objects, like popping up windows and
> > frames.
> 
> Each CanvasItem can have callbacks for mouse move, click, key press and so 
> on. 
>   The idea is to have separate CanvasItems for the items that should react to 
> mouse events and then register callbacks for those events.  The callback then 
> pops up windows or whatever.

Which means running Lisp from redisplay, something we currently barely
support and generally discourage.

> It is a more event driven approach, and that in itself is a big modification 
> for Emacs which is more sequential in nature.

I understand the approach.  I'm trying to see how this approach can be
used without throwing most of the Emacs design out the window.