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 18:14:36 +0300 Message-ID: <83vd8gg4kj.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> <83630hgi0r.fsf@gnu.org> <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> 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 1279207613 11811 80.91.229.12 (15 Jul 2010 15:26:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2010 15:26:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 15 17:26:52 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 1OZQKo-0003i4-96 for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 17:26:50 +0200 Original-Received: from localhost ([127.0.0.1]:50037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZQKn-000311-I2 for ged-emacs-devel@m.gmane.org; Thu, 15 Jul 2010 11:26:49 -0400 Original-Received: from [140.186.70.92] (port=36701 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZQHN-0001Ef-4w for emacs-devel@gnu.org; Thu, 15 Jul 2010 11:23:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZQBj-0003e8-SO for emacs-devel@gnu.org; Thu, 15 Jul 2010 11:17:28 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:62079) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZQBj-0003dr-JN for emacs-devel@gnu.org; Thu, 15 Jul 2010 11:17:27 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L5L00300UEYUU00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Thu, 15 Jul 2010 18:16:32 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.120.144]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5L001T1UFJTB70@a-mtaout21.012.net.il>; Thu, 15 Jul 2010 18:16:32 +0300 (IDT) In-reply-to: <87fwzkbzg8.fsf@telefonica.net> 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:127363 Archived-At: > From: =C3=93scar Fuentes > Date: Thu, 15 Jul 2010 16:18:47 +0200 >=20 > From your discussion it seems that the only serious "problem" with = Emacs > and Gnome's canvas (or any other canvas) is coupling the Emacs disp= lay > system with it. I wish! That was just the first thing on my mind after reading that white paper. The tip of the iceberg, so to say. There are other "lesser" considerations, that are nevertheless quite serious and should be considered up front. I already mentioned the fact that input processing and the whole logi= c of the Emacs idle loop will need to be reconsidered and modified. A few more examples of the issues that need to be considered: . We represent characters as a super-set of Unicode, using upper planes for characters that are not unified (for cultural reasons) and eight-bit raw bytes. I'm quite sure Canvas can deal with UTF-8 encoded characters, but what will it do with codepoints tha= t extend Unicode? How to tell it which fonts to use for them and how to interpret them in general? . Display of composed characters. Emacs specifies compositions via either (a) text properties or (b) char-tables. I'm quite sure that display of composed character is supported by Canvas, but ho= w to we communicate the above two types of specifications from Emac= s to Canvas? . Jan says we need to maintain a GtkTextBuffer object for every buffer we have in Emacs. Does that mean buffer text will be held twice in memory, once as it is today, the other as GtkTextBuffer? What will that do to Emacs's ability to visit very large files? Even today there's demand to be able to visit files that are 1GB or 2GB in size. Doubling that would be a serious impediment. Or maybe you are thinking about _replacing_ buffer text with GtkTextBuffer? That would mean you'd need to redesign buffer management code. And those are just examples. > My plan is radical: bypass the current Emacs display system > and implement a new one on top of the canvas. This would be purely > event-driven, hopefully with very little special cases for the plat= forms > where Emacs runs, and substantially simpler because the canvas woul= d > take care of the low level chores. >=20 > On the long term, this could allow to remove the GUI code from the = current > display system and left the tty code alone. >=20 > If the display system is decoupled from the buffer-handling code, t= he > high-level event system (Elisp hooks, etc) and the rest of Emacs in > general, it could be doable with a reasonable amount of work for a > single developer. Maybe I'm being too optimistic. I hope you are not overly optimistic, and I wish you success. I really do. But because there's no formal specification of the Emacs display system, you have no exhaustive list of requirements which you will need to implement. May I suggest to begin with some process of requirements capture? That would at least allow to produce some kind of plan, identify the possible difficulties, and outline ways of overcoming them. Note that doing what you want will touch not only the display, but also all of the basic objects and probably change quite a lot the whole top-level architecture. That kind of open hear= t surgery is not recommended without at least some prior analysis. And since no one knows enough of Emacs internals in enough detail, no single person can do all that and succeed. Just to put things in perspective: the integration of bidi reordering into the display engine was intensively discussed over a period of 2 years, with active participation of Gerd M=C3=B6llmann, the architect= and implementor of the current display code. At least 2 other designs were proposed (and one of them was even implemented) and rejected, before the current design was agreed upon. Needless to say, the bidi support is nowhere near the redesign you are proposing, in terms of complexity and overall effect on parts of Emacs outside display proper. I'm not trying to spook you off, and I really welcome an attempt to revamp the display engine. I'm just saying that without some minimal analysis of requirements and possible high-level design decisions, this project will have very small chance of delivering.