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: Why Emacs should have a good web-browser Date: Wed, 22 Jul 2009 01:31:23 +0900 Message-ID: <87iqhm3smc.fsf@catnip.gol.com> References: <87ocrjl2r6.fsf@gmail.com> <87zlb2bwyj.fsf@catnip.gol.com> <87bpnefl73.fsf@gmail.com> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1248193994 3833 80.91.229.12 (21 Jul 2009 16:33:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jul 2009 16:33:14 +0000 (UTC) Cc: ferkiwi+a@gmail.com, Paul R , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 18:33:07 2009 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.50) id 1MTIH4-0005Qt-Ur for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 18:33:07 +0200 Original-Received: from localhost ([127.0.0.1]:41257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTIH4-0001uw-Dd for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 12:33:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTIFu-0001KX-2r for emacs-devel@gnu.org; Tue, 21 Jul 2009 12:31:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTIFp-0001Ih-IN for emacs-devel@gnu.org; Tue, 21 Jul 2009 12:31:53 -0400 Original-Received: from [199.232.76.173] (port=41549 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTIFp-0001IX-5n for emacs-devel@gnu.org; Tue, 21 Jul 2009 12:31:49 -0400 Original-Received: from smtp12.dentaku.gol.com ([203.216.5.74]:48948) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTIFW-0002aI-92; Tue, 21 Jul 2009 12:31:30 -0400 Original-Received: from 218.231.109.150.eo.eaccess.ne.jp ([218.231.109.150] helo=catnip.gol.com) by smtp12.dentaku.gol.com with esmtpa (Dentaku) id 1MTIFP-0001f6-Ut; Wed, 22 Jul 2009 01:31:24 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 340FADF6F; Wed, 22 Jul 2009 01:31:23 +0900 (JST) System-Type: x86_64-unknown-linux-gnu In-Reply-To: (Stefan Monnier's message of "Tue, 21 Jul 2009 11:52:28 -0400") Original-Lines: 42 X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-detected-operating-system: by monty-python.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:112926 Archived-At: Stefan Monnier writes: >> This is a very na=C3=AFve suggestion, as I dont know much of emacs displ= ay >> engine. I just notice that emacs wants to display formated text, with >> hyperlinks, colors, pictures, antialiasing, etc. All of that (and much >> more, like complex layouts, tables, etc) is already very well adressed >> in an xhtml/css+js engine such as gecko or webkit, both free software >> and available for integration in third party applications. > > It might be possible to use one of those engines as Emacs's rendering > engine, indeed. To me, it wouldn't seem like an good solution to the > problem at hand because I don't think it would allow me to control the > web-browser from Emacs (e.g., how would I access from Elisp the content > of pages generated from HTML?). So it'd be more like embedding Emacs > inside a normal browser. It's not a bad idea, but I don't think it'll > provide as many benefits from Emacs's point of view. If Emacs used the "high level" rendering component, I dunno how well it would work, as an Emacs buffer is pretty different than a web page. Most obviously, it's dynamic, and changing it is expected to be very cheap even if the buffer is huge. Another issue might be that, to the best of my knowledge, html rendering engines tend to generate a "rendered" representation of the entire page, no matter how little of it is displayed (as opposed to Emacs, which does the most expensive processing mostly only the parts of a buffer that are displayed). This has obvious benefits (e.g., scrolling around after the long initial setup can be fast, and your scrollbar can easily show physical display units), but has obvious problems too: displaying a 1GB file might take a l.o.n.g time to show the first page.... I don't know how well these engines deal with the underlying text changing; given that a small text change might affect the _entire_ "rendered" data structure, there seems a good chance the answer might be "not very well." But all of this is mostly speculation on my part... -Miles --=20 Bore, n. A person who talks when you wish him to listen.