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

[Thomas Lord]

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