From: Thomas Lord <lord@emf.net>
To: Antoine Levitt <smeuuh@gmail.com>
Cc: rms@gnu.org, pmr@pajato.com, Chong Yidong <cyd@stupidchicken.com>,
lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org,
monnier@iro.umontreal.ca, raman@users.sourceforge.net,
phil@shellarchive.co.uk
Subject: Re: An Emacs plug-in for a browser (Firefox?)
Date: Mon, 08 Sep 2008 13:27:14 -0700 [thread overview]
Message-ID: <48C58AA2.5090200@emf.net> (raw)
In-Reply-To: <6fa54e4e0809081207m6133393fs3c43af4469778695@mail.gmail.com>
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 <lord@emf.net <mailto: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
>
>
>
next prev parent reply other threads:[~2008-09-08 20:27 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-04 22:18 An Emacs plug-in for a browser (Firefox?) Paul Michael Reilly
2008-09-05 0:16 ` David De La Harpe Golden
2008-09-05 0:19 ` David House
2008-09-05 2:42 ` T. V. Raman
2008-09-05 4:53 ` Paul Michael Reilly
2008-09-05 6:44 ` joakim
2008-09-05 8:53 ` Phil Jackson
2008-09-05 9:21 ` joakim
2008-09-05 9:30 ` Lennart Borgman (gmail)
2008-09-05 11:20 ` Antoine Levitt
2008-09-06 7:12 ` Richard M. Stallman
2008-09-06 10:48 ` Antoine Levitt
2008-09-06 21:04 ` Richard M. Stallman
2008-09-06 21:36 ` David Hansen
2008-09-06 21:49 ` Lennart Borgman (gmail)
2008-09-06 22:25 ` David Hansen
2008-09-06 22:48 ` Lennart Borgman (gmail)
2008-09-06 23:08 ` David Hansen
2008-09-06 22:41 ` Sean O'Rourke
2008-09-07 23:36 ` Richard M. Stallman
2008-09-06 16:42 ` Chong Yidong
2008-09-06 16:58 ` joakim
2008-09-06 19:42 ` Chong Yidong
2008-09-06 20:20 ` David Hansen
2008-09-06 21:54 ` T. V. Raman
2008-09-06 20:11 ` Stefan Monnier
2008-09-07 17:39 ` Richard M. Stallman
2008-09-07 17:49 ` Lennart Borgman (gmail)
2008-09-07 18:29 ` Chong Yidong
2008-09-08 9:22 ` Richard M. Stallman
2008-09-08 12:31 ` Chong Yidong
2008-09-08 17:07 ` Antoine Levitt
2008-09-08 19:05 ` Thomas Lord
2008-09-08 19:07 ` Antoine Levitt
2008-09-08 20:27 ` Thomas Lord [this message]
2008-09-08 20:34 ` Stefan Monnier
2008-09-08 21:33 ` joakim
2008-09-08 21:46 ` Thomas Lord
2008-09-09 8:11 ` Richard M. Stallman
2008-09-08 22:13 ` Richard M. Stallman
2008-09-07 19:55 ` Stefan Monnier
2008-09-08 9:22 ` Richard M. Stallman
2008-09-05 13:33 ` T. V. Raman
2008-09-05 13:32 ` T. V. Raman
2008-09-05 20:40 ` Christian Faulhammer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48C58AA2.5090200@emf.net \
--to=lord@emf.net \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=lennart.borgman@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=phil@shellarchive.co.uk \
--cc=pmr@pajato.com \
--cc=raman@users.sourceforge.net \
--cc=rms@gnu.org \
--cc=smeuuh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.