Re: An Emacs plug-in for a browser (Firefox?)

["Antoine Levitt" <smeuuh@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]

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
>
>
>

[-- Attachment #2: Type: text/html, Size: 3306 bytes --]