From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Fri, 16 Jul 2010 15:33:13 +0900 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> <83vd8gg4kj.fsf@gnu.org> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279262015 11250 80.91.229.12 (16 Jul 2010 06:33:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Jul 2010 06:33:35 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 16 08:33:32 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 1OZeUF-0001hD-Hj for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 08:33:31 +0200 Original-Received: from localhost ([127.0.0.1]:34907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZeUE-00027P-Rt for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 02:33:30 -0400 Original-Received: from [140.186.70.92] (port=55130 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZeU5-00025F-2d for emacs-devel@gnu.org; Fri, 16 Jul 2010 02:33:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZeU4-0005k9-6K for emacs-devel@gnu.org; Fri, 16 Jul 2010 02:33:21 -0400 Original-Received: from tyo202.gate.nec.co.jp ([202.32.8.206]:49930) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZeU2-0005jq-3P; Fri, 16 Jul 2010 02:33:18 -0400 Original-Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o6G6XF0m025527; Fri, 16 Jul 2010 15:33:15 +0900 (JST) Original-Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o6G6XFU18912; Fri, 16 Jul 2010 15:33:15 +0900 (JST) Original-Received: from relay31.aps.necel.com ([10.29.19.54]) by vgate01.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id o6G6XE411721; Fri, 16 Jul 2010 15:33:14 +0900 (JST) Original-Received: from relay61.aps.necel.com ([10.29.19.24] [10.29.19.24]) by relay31.aps.necel.com with ESMTP; Fri, 16 Jul 2010 15:33:14 +0900 Original-Received: from dhlpc061 ([10.114.113.142] [10.114.113.142]) by relay61.aps.necel.com with ESMTP; Fri, 16 Jul 2010 15:33:14 +0900 Original-Received: by dhlpc061 (Postfix, from userid 31295) id 044A352E222; Fri, 16 Jul 2010 15:33:13 +0900 (JST) System-Type: x86_64-unknown-linux-gnu Blat: Foop In-Reply-To: <83vd8gg4kj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Jul 2010 18:14:36 +0300") Original-Lines: 46 X-detected-operating-system: by eggs.gnu.org: Solaris 8 (1) 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:127410 Archived-At: Eli Zaretskii writes: > . 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. ... and it's not just memory -- a serious problem with many "pre-rendered" text display implementations (e.g., most web-browsers) is that there's a _massive_ delay/slowdown when displaying a huge documents. [Most people don't display huge documents (especially in web-browsers etc), of course, so these implementations work OK for "typical" use. But AFAICT, it's definitely an important goal of Emacs to handle more extreme cases too.] > Or maybe you are thinking about _replacing_ buffer text with > GtkTextBuffer? That would mean you'd need to redesign buffer > management code. and pretty much rewrite or toss out a lot of lisp code that uses any but the most basic features. I think code re-use and sharing commonly used libraries is a very good thing, and should be done as often as practical -- but I just don't think it's practical in the case of Emacs buffers/high-level-redisplay. Emacs is simply too different. [If someone wanted to _rewrite_ emacs from scratch, not maintaining compatibility with the vast majority of legacy code, this would likely be a good route to follow of course (though even in that case, there's always the possibility that implementations like GtkTextBuffer are simply not good enough to handle more hardcore use).] Of course, using a lower-level interface, e.g., GTK/cairo/whatever as a drawing library (which Emacs redisplay would call to display), instead of e.g. X, would probably be practical though, and might even be fairly easy to do given that the drawing layer already has an abstract interface because of the various backends already supported. -Miles -- Once, adj. Enough.