From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Antoine Levitt" Newsgroups: gmane.emacs.devel Subject: Re: An Emacs plug-in for a browser (Firefox?) Date: Mon, 8 Sep 2008 21:07:24 +0200 Message-ID: <6fa54e4e0809081207m6133393fs3c43af4469778695@mail.gmail.com> References: <6fa54e4e0809050420i5132ace5red5a011b69ecd1ed@mail.gmail.com> <8763p795cq.fsf@cyd.mit.edu> <87iqt6q0na.fsf@cyd.mit.edu> <6fa54e4e0809081007l68f1df2ei71450cf3483f2d17@mail.gmail.com> <48C5778F.2020203@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_93822_16485593.1220900844665" X-Trace: ger.gmane.org 1220900862 32428 80.91.229.12 (8 Sep 2008 19:07:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2008 19:07:42 +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: "Thomas Lord" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 08 21:08:36 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 1Kcm6F-0004IO-D1 for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 21:08:35 +0200 Original-Received: from localhost ([127.0.0.1]:38969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kcm5F-000687-IC for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 15:07:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kcm5A-00067f-1R for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:07:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kcm58-00065l-T2 for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:07:27 -0400 Original-Received: from [199.232.76.173] (port=58575 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kcm58-00065K-N9 for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:07:26 -0400 Original-Received: from gv-out-0910.google.com ([216.239.58.187]:54179) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kcm58-0006rN-4u for emacs-devel@gnu.org; Mon, 08 Sep 2008 15:07:26 -0400 Original-Received: by gv-out-0910.google.com with SMTP id i36so286764gve.17 for ; Mon, 08 Sep 2008 12:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=vc66BWWr1xoZKhEU3r4a7DpSWn2YjjmkrNP7d1dPMwg=; b=OMH8EP+CsWI5Gd8XEgXKXwurOiraEsaQRqaQ8zI8N6WPJ9FhS/QLba2xpufuyEGNdX I+yW2rr7MwzrcIWfcXBKmpA8tKRE3EG4ZKY9cPklOlw8hSq2ZhjKS9t8mCfWzuHk8CIm 7fKJztwJHnhQYFiV/wnAN+g5Vvr0f03C4X36I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=F2WU6WT+2ZHMo10NZEN29BqjLsuckuXDfOdk18iiSE/DcJ+7Saz6wi2qZWEU5rAaB1 G+m07OiDljBVXQZkjpbwZwSF8I9V/YDhbTOC+NM+TIuzHkzp5bl1wdWZ9jRP6HTkbxAz i2iLtUmDh1jeW0Tx+uoaCu/xH8w9bjL2e+lqU= Original-Received: by 10.210.28.6 with SMTP id b6mr19235835ebb.60.1220900844686; Mon, 08 Sep 2008 12:07:24 -0700 (PDT) Original-Received: by 10.210.141.18 with HTTP; Mon, 8 Sep 2008 12:07:24 -0700 (PDT) In-Reply-To: <48C5778F.2020203@emf.net> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:103698 Archived-At: ------=_Part_93822_16485593.1220900844665 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 ? 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 > > > ------=_Part_93822_16485593.1220900844665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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 ?
Feel free to correct me if that view is overly naive.
2008/9/8 Thomas Lord <lord@emf.net>
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



------=_Part_93822_16485593.1220900844665--