Re: Emacs and Gnome Canvas

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> I know from the start that the stuff I'll use *if* the plan goes
>> ahead is not acceptable for key Emacs developers
>
> Why the defeatism?

I would use Qt, hence C++, not being shy about using advanced language
features if necessary. That is for getting a working system as soon as
possible.

[snip]

>> Anyways, I'm not interested on learning about the current display
>> engine.
>
> How you will be able to implement a new display engine without at
> least some familiarity with what the current one does?

I expect that if the internal layout of the data to be displayed is
clear enough, that is sufficient for the display engine writer. I mean,
knowing "this represents a text property" is what you need. Knowing how
the current display engine deals with it shouldn't be necessary. I'm
sure there is a lot of wisdom on the current display system wrt dealing
with difficulties of representing Emacs' data on a screen, but I suspect
that learn-by-doing is faster than stopping everything while one studies
the details of the current implementation and elaborated plans. I have a
tendency to analysis-paralysis and that approach won't work for me on
hobby projects :-)

>> I'm more interested on a simpler approach: here is the data, display
>> it.
>
> This isn't Emacs.  You are describing Gnuplot.  The most important
> problem a display engine needs to solve is: here's the new data and
> the old display, now update the display.  And the data is not all
> given in one place.

That's implicit in the above. The "data" contains info about what
changed.

>> 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.
>
> What do you mean by ``tightly coupled''?  The current display stops if
> input becomes available -- is that tight enough?

No, that's fine because the low-level input handling will be part of the
new system. By "tightly coupled" I mean there are blurred areas where it
is hard to say if they belong to the display engine or to other
system. Ideally, if Emacs were well modularized, adding a new display
engine wouldn't require any modifications to other areas.

> In general, if you make all kinds of assumptions that would break your
> approach, I'd suggest to publish those assumptions -- that's the
> fastest way to validating them, short of studying the code yourself.

That's a good idea.