[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs and Gnome Canvas
From: |
Óscar Fuentes |
Subject: |
Re: Emacs and Gnome Canvas |
Date: |
Thu, 15 Jul 2010 19:48:50 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> 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.
- Re: Emacs and Gnome Canvas, (continued)
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas, Miles Bader, 2010/07/16
- Re: Emacs and Gnome Canvas, Chong Yidong, 2010/07/15
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas,
Óscar Fuentes <=
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/16
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/16
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/16
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/16
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/16
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/16
- Re: Emacs and Gnome Canvas, Chad Brown, 2010/07/16
- Re: Emacs and Gnome Canvas, Óscar Fuentes, 2010/07/16