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
<address@hidden>
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.
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