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 12:05:51 -0700 Message-ID: <48C5778F.2020203@emf.net> References: <48C0FC53.4020806@gmail.com> <6fa54e4e0809050420i5132ace5red5a011b69ecd1ed@mail.gmail.com> <8763p795cq.fsf@cyd.mit.edu> <87iqt6q0na.fsf@cyd.mit.edu> <6fa54e4e0809081007l68f1df2ei71450cf3483f2d17@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 1220897676 20400 80.91.229.12 (8 Sep 2008 18:14:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2008 18:14:36 +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 20:15:30 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 1KclGl-0004OQ-0H for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 20:15:23 +0200 Original-Received: from localhost ([127.0.0.1]:52850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KclFk-0005Sb-KN for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 14:14:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KclFg-0005Rp-Ar for emacs-devel@gnu.org; Mon, 08 Sep 2008 14:14:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KclFf-0005RP-0V for emacs-devel@gnu.org; Mon, 08 Sep 2008 14:14:15 -0400 Original-Received: from [199.232.76.173] (port=37444 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KclFe-0005RM-QO for emacs-devel@gnu.org; Mon, 08 Sep 2008 14:14:14 -0400 Original-Received: from smtp211.iad.emailsrvr.com ([207.97.245.211]:49187) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KclFd-00059D-NG for emacs-devel@gnu.org; Mon, 08 Sep 2008 14:14:14 -0400 Original-Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9EE861B4021; Mon, 8 Sep 2008 14:14:07 -0400 (EDT) Original-Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTP id 2C1DD1B47D3; Mon, 8 Sep 2008 14:14:06 -0400 (EDT) User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <6fa54e4e0809081007l68f1df2ei71450cf3483f2d17@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:103697 Archived-At: 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 > 2008/9/8 Chong Yidong > > > "Richard M. Stallman" > writes: > > > Switching constantly between Emacs and Firefox (e.g., by > making Emacs > > open links via a separate Firefox application) is inefficient. > > > > When you say "switching", what does that refer to? > > Are you talking about a UI-level operation? > > Yes. > > > In what sense is it inefficient? > > In the same sense that it's less efficient to perform shell operations > in a separate xterm, rather than doing M-! or M-x grep or M-x gdb etc. > For instance, it's more cumbersome to arrange to view the browser > display and side by side with Emacs, since the browser isn't > constrained > to an Emacs window. > >