Re: Emacs and Gnome Canvas

[Óscar Fuentes]

Chong Yidong <address@hidden> writes:

> Óscar Fuentes <address@hidden> writes:
>
>> AFAIK the display system have evolved from the tty one by incremental
>> updates
>
> No, the redisplay system was redesigned during Emacs 21 specifically
> with both tty and graphical terminals in mind.  It did not evolve
> mindlessly; the design has a very specific logic behind it.  As long as
> we support tty, there is no getting rid of the redisplay iterator.

What I'm thinking on is not to remove the current display system. Is
about implementing a parallel one. I know from the start that the stuff
I'll use *if* the plan goes ahead is not acceptable for key Emacs
developers, so it would be a throw-away project, but nevertheless it
would give information about what can be expected from that approach.

[snip]

> It is still not too clear to me what we would gain from a Canvas-type
> revamp of redisplay, relative to the large costs involved.  It does not
> seem like a promising avenue of development.

One of the main insights we could get from the experimental plan I
referred to above is to know the cost/benefit ratio.

> A more promising route is the one that Yamamoto Mitsuharu has explored,
> mentioned earlier in this thread, which (IIUC) treats Cairo as a
> graphical terminal to render onto, on the same footing as the
> tty/X/Windows/NS terminals.  Here, I can see a reasonable path to real
> improvement.  For example, it might allow us to use the GTK printing
> infrastructure, which operates on Cairo contexts.  If you are interested
> in redisplay development, that is the direction I'd suggest looking
> into.

Would that system allow to draw UML diagrams with real graphics, instead
of ASCII? Would it allow to implement a real graphical view for the DAG
of a dVCS history? In short, would it a real drawing surface where you
can draw arbitrary stuff and react to user actions such as the user
clicking and dragging a line, preferably from Elisp code?

Anyways, I'm not interested on learning about the current display
engine. I was told that it is very complex and only a few gurus have a
real grasp of it, so very likely adding the features I'll like to see in
Emacs would be a daunting task. I'm more interested on a simpler
approach: here is the data, display it. The only thing I really fear is
finding that other parts of Emacs (high-level event handling or content
change management, for instance) are tightly coupled with the current
display engine.