From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: An Emacs plug-in for a browser (Firefox?) Date: Mon, 08 Sep 2008 13:27:14 -0700 Message-ID: <48C58AA2.5090200@emf.net> References: <6fa54e4e0809050420i5132ace5red5a011b69ecd1ed@mail.gmail.com> <8763p795cq.fsf@cyd.mit.edu> <87iqt6q0na.fsf@cyd.mit.edu> <6fa54e4e0809081007l68f1df2ei71450cf3483f2d17@mail.gmail.com> <48C5778F.2020203@emf.net> <6fa54e4e0809081207m6133393fs3c43af4469778695@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220902546 6396 80.91.229.12 (8 Sep 2008 19:35:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2008 19:35:46 +0000 (UTC) Cc: rms@gnu.org, pmr@pajato.com, Chong Yidong , lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, monnier@iro.umontreal.ca, raman@users.sourceforge.net, phil@shellarchive.co.uk To: Antoine Levitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 08 21:36:40 2008 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 1KcmXP-0004t1-Mg for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 21:36:40 +0200 Original-Received: from localhost ([127.0.0.1]:42567 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcmWP-0001zF-Eq for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 15:35:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcmWL-0001yY-7v for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:35:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcmWI-0001xd-Qr for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:35:31 -0400 Original-Received: from [199.232.76.173] (port=36247 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcmWI-0001xa-Hf for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:35:30 -0400 Original-Received: from smtp191.iad.emailsrvr.com ([207.97.245.191]:43696) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KcmWH-0003zF-WC for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:35:30 -0400 Original-Received: from relay9.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id C69279B01E6; Mon, 8 Sep 2008 15:35:28 -0400 (EDT) Original-Received: by relay9.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTP id DF2D39B01D1; Mon, 8 Sep 2008 15:35:26 -0400 (EDT) User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <6fa54e4e0809081207m6133393fs3c43af4469778695@mail.gmail.com> X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:103700 Archived-At: Antoine Levitt wrote: > I don't see how this is an issue, in theory at least. > I suppose the communication with the embedded process looks like : you > transmit user information (keypresses, mouse clicks), and get back > graphics. Let's say you have done C-x 2, and have two windows of the > same web buffer. You scroll the top one, emacs sends to the process > "hey man, scroll down". Which triggers a GTK redisplay, and both > windows are scrolled. Sure, you don't have independance of the two > windows, but that's not that important, is it ? Which of the two window sizes should be used for rendering? How should the other window's display be constructed from that? Also, remember that you likely aren't "getting back graphics" but, rather, the browser part is probably talking directly to the window system -- and expects to be painting just one window. Where do the pixels in the other window come from, especially given that it might be a different size? Years ago, as I recall, when RMS saw the Andrew Toolkit (a user interface toolkit) he added a task to the Emacs wish-list: to embed X11 windows from other projects. It's still not a bad idea but it doesn't make a lot of sense in the general case -- it can only work when the application running those windows can, like Emacs, handle multiple views of a single model. NO standard-conforming browser can be an example of a program that handles multiple views of a single model BECAUSE the W3C and ECMA standards that pertain to what a browser is supposed to do don't allow for that possibility. W3C screwed up (if you think multiple views are important). -t > Feel free to correct me if that view is overly naive. > 2008/9/8 Thomas Lord > > > Antoine Levitt wrote: > > Having browser windows in emacs would also allow allow users > to benefit from emacs window capabilities (fuzzy completion > with ido-mode, listing/filter with ibuffer, tabs, side-by-side > splitting, and basically whatever else folks decide to code in > elisp). Classical web browser basically have tabs, and > keybindings to next/previous tabs. Emacs would make it much > more powerful. > Besides, as many people noted, it shouldn't be hard to do, > since technologies to do so already exist. IMHO, the tough > step is getting text and textboxes recognised by emacs, but > even without that, it'd still be amazing. > Good luck to you joakim, and please consider browsers as an > equally useful target of embedding as multimedia apps. > > > It won't work, unfortunately. It's a lovely fantasy for > a nice system -- I like the sentiment -- but it won't (can't) > work: > > Emacs has the concept that two windows can look at the same > buffer. > > HTML/DOM/CSS/Javascript are based on the assumption > that only one window exists for a given page. This > assumption is deeply reflected in the APIs and data structures. > > Imagining an Emacs window containing a browser view > of some page, any behavior you define for what C-x 2 > (split-window-vertically) does (for example) will have > to be kludgey. Javascript expects a single window. > Events aren't tagged with a window. Geometry control, > spread over the DOM and CSS, is often in terms of the > absolute geometry of the One window. It's really, > really, deeply rooted. > > This is one that W3C/ECMA got badly wrong, unfortunately. > There's no way to fix it thoroughly other than several > new W3C/ECMA standards that deprecate several existing > standards with which there won't be upward compatibility. > Basically, standards committees will need to pick a kludge, > describe that in several different standards, and then make > up entirely new and incompatible alternatives to the > kludge. They really messed up (if you believe that multiple > views on a single model are important). > > > -t > > >