From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Thu, 15 Jul 2010 19:48:50 +0200 Message-ID: <8739vkbpq5.fsf@telefonica.net> References: <4C3CD120.4040905@swipnet.se> <5A91499A-0470-43FD-9F48-560CEAD3424C@mit.edu> <83wrsyr068.fsf@gnu.org> <83iq4hhjww.fsf@gnu.org> <87sk3lbvv0.fsf@telefonica.net> <83hbk1grnq.fsf@gnu.org> <4C3EBCDC.8050709@swipnet.se> <83d3upgmwj.fsf@gnu.org> <4C3ECB4C.6050208@swipnet.se> <83aaptgly1.fsf@gnu.org> <4C3ED4F9.4080603@swipnet.se> <83630hgi0r.fsf@gnu.org> <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> <877hkwag6y.fsf@stupidchicken.com> <877hkwbth6.fsf@telefonica.net> <83pqyofzdg.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279216157 11763 80.91.229.12 (15 Jul 2010 17:49:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2010 17:49:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 15 19:49:16 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OZSYb-0000sC-Ne for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 19:49:14 +0200 Original-Received: from localhost ([127.0.0.1]:41434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZSYb-0006k4-4j for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 13:49:13 -0400 Original-Received: from [140.186.70.92] (port=35867 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZSYR-0006iZ-Eu for emacs-devel@gnu.org; Thu, 15 Jul 2010 13:49:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZSYP-0001tw-Ew for emacs-devel@gnu.org; Thu, 15 Jul 2010 13:49:02 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:33859) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZSYP-0001tO-2G for emacs-devel@gnu.org; Thu, 15 Jul 2010 13:49:01 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OZSYM-0000ic-NV for emacs-devel@gnu.org; Thu, 15 Jul 2010 19:48:58 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jul 2010 19:48:58 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jul 2010 19:48:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 59 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:M7FueM9NOlAUsrQ1vDqkitIHMwA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127383 Archived-At: Eli Zaretskii 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.