From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Thu, 22 Jul 2010 16:26:36 +0200 Message-ID: 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> <8739vkbpq5.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279808820 5587 80.91.229.12 (22 Jul 2010 14:27:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Jul 2010 14:27:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 22 16:26:56 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 1Obwjf-0008PI-Or for ged-emacs-devel@m.gmane.org; Thu, 22 Jul 2010 16:26:56 +0200 Original-Received: from localhost ([127.0.0.1]:35438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Obwje-0004oE-M2 for ged-emacs-devel@m.gmane.org; Thu, 22 Jul 2010 10:26:54 -0400 Original-Received: from [140.186.70.92] (port=58856 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObwjU-0004nx-0U for emacs-devel@gnu.org; Thu, 22 Jul 2010 10:26:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObwjS-0001hO-Qb for emacs-devel@gnu.org; Thu, 22 Jul 2010 10:26:43 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:51980) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObwjS-0001gt-Mj for emacs-devel@gnu.org; Thu, 22 Jul 2010 10:26:42 -0400 Original-Received: from ceviche.home (vpn-132-204-232-131.acd.umontreal.ca [132.204.232.131]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o6MEQbLv015277; Thu, 22 Jul 2010 10:26:38 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id E693B660D2; Thu, 22 Jul 2010 16:26:36 +0200 (CEST) In-Reply-To: <8739vkbpq5.fsf@telefonica.net> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Thu, 15 Jul 2010 19:48:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3583=0 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:127637 Archived-At: >>> 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. I think this will be the hard part: Emacs doesn't keep track very precisely of which data it changes. It might keep track of which windows/buffers were affected, as well as maybe a containing region, but that's about it. It "often" (not that often, but often enough that it should be handled passably fast) ends up saying "just redisplay it all" because the changes have too far-reaching consequences to keep track of them. If it can be made to work, then it's an interesting direction, because it basically dumps the responsibility of handling redisplay to some external library. I don't think trying to handle all the current display features makes sense as a starting goal, BTW. Better start small and add features one by one as you encounter them. You'll want to rewrite the code at some point anyway, so there's no need to spend too much time designing upfront. Stefan