From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Thu, 15 Jul 2010 13:24:04 +0300 Message-ID: <83630hgi0r.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1279189601 10832 80.91.229.12 (15 Jul 2010 10:26:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2010 10:26:41 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: =?UTF-8?B?SmFuIERqw6Rydg==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 15 12:26:39 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 1OZLeI-00054B-On for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 12:26:39 +0200 Original-Received: from localhost ([127.0.0.1]:49690 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZLeH-0004Ks-SL for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 06:26:37 -0400 Original-Received: from [140.186.70.92] (port=57301 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZLe9-0004KG-9X for emacs-devel@gnu.org; Thu, 15 Jul 2010 06:26:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZLe7-0002EM-P7 for emacs-devel@gnu.org; Thu, 15 Jul 2010 06:26:29 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:59354) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZLe7-0002E9-HK for emacs-devel@gnu.org; Thu, 15 Jul 2010 06:26:27 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L5L00G00GXFKH00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Thu, 15 Jul 2010 13:26:01 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.120.144]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5L00DZGGZC3PC0@a-mtaout21.012.net.il>; Thu, 15 Jul 2010 13:26:01 +0300 (IDT) In-reply-to: <4C3ED4F9.4080603@swipnet.se> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:127346 Archived-At: > Date: Thu, 15 Jul 2010 11:29:29 +0200 > From: Jan Dj=C3=A4rv > CC: ofv@wanadoo.es, emacs-devel@gnu.org >=20 > > But the inserted character could be in the portion that is not > > displayed at all, in which case it does not "require redisplay". = Who > > should decide whether redisplay is necessary? If that's Emacs, t= hen > > it should know a lot about the display layout. If its the Canvas= , > > then it should know a lot about what portions of the buffer text = are > > on the screen. >=20 > You probably have your text in an CanvasItem that has a GtkTextBuff= er. When a=20 > character is inserted, you insert in to the GtkTextBuffer. The red= isplay part=20 > is then handeled internally between GtkTextBuffer, GnomeCanvas(Rich= )TextItem=20 > and GnomeCanvas. >=20 > As I said, it probably relies on having all text in the GtkTextBuff= er. But GtkTextBuffer needs text with attributes, right? Currently, we compute these attributes as part of redisplay, and only for the displayed portion of the text. Using GtkTextBuffer, it seems like we will need to have a part (or an equivalent) of that redisplay code, which would need to recompute the attributes for _all_ of the text, after each modification of buffer text? How can this be fast enough? E.g., what if I'm viewing a large log file with non-trivial fontification and clickable parts? And what about redisplay optimizations? For example, we now have a special method that updates a window if the only change is that point moved. We don't care _why_ it moved -- there could be any number of input events that cause this. However, _determining_ that only point moved is a non-trivial job, which examines about a dozen conditions o= n some internal variables and flags. Then there's another non-trivial job: where on screen to move the cursor given the position of point. If the communications with the Canvas is by means of a GtkTextBuffer, how can these chores be done? Won't we need to regenerate the GtkTextBuffer, or at least its large parts, even when the only change is point movement? > >>> How about an arbitrary mouse move? > >> > >> If it resulted in a different highlightning of a link, yes. > > > > Again, how to know that? Note that some mouse movements perform > > complex operations on Emacs objects, like popping up windows and > > frames. >=20 > Each CanvasItem can have callbacks for mouse move, click, key press= and so on.=20 > The idea is to have separate CanvasItems for the items that shoul= d react to=20 > mouse events and then register callbacks for those events. The cal= lback then=20 > pops up windows or whatever. Which means running Lisp from redisplay, something we currently barel= y support and generally discourage. > It is a more event driven approach, and that in itself is a big mod= ification=20 > for Emacs which is more sequential in nature. I understand the approach. I'm trying to see how this approach can b= e used without throwing most of the Emacs design out the window.