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

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

[Paul Michael Reilly]

Steve Yegge, always an interesting read, recently opined that two of
his "essential" tools are Emacs and Firefox.  And claimed that if one
were to subsume the other life would be nearly perfect, in at least
one sense.

While there are a few very useful Emacs add-ons that allow you to use
emacsclient to edit text in Mozilla based tools (Thunderbird and
Firefox come to mind), I've always wondered why someone has not hacked
a plugin that support some sort of Emacs url.  For example,
"emacs://x.y.z/some/file/or/other.txt" when presented to the browser
would fire up a tab on the browser with a full blown Emacs instance
"embedded/buried" in it and edit the file other.txt with the full
power of Emacs immersed in the browser.  Sandbox issues aside, what
other issues need to be overcome to create such a browser plugin?

-pmr

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

[David De La Harpe Golden]

Paul Michael Reilly wrote:

> For example,
> "emacs://x.y.z/some/file/or/other.txt" when presented to the browser
> would fire up a tab on the browser with a full blown Emacs instance
> "embedded/buried" in it and edit the file other.txt with the full
> power of Emacs immersed in the browser.  Sandbox issues aside, what
> other issues need to be overcome to create such a browser plugin?
> 

Probably lots for full generality and security; but emacs IIRC already
supports the xembed protocol on X11 (--parent-id command line arg?), so
making a basic plugin for firefox should be straightforward on X11
platforms, since firefox also supports xembedding as part of its
extended plugin api on X11.

http://developer.mozilla.org/En/Plugins
- tells you how to write plugins.

http://developer.mozilla.org/en/XEmbed_Extension_for_Mozilla_Plugins
- tells you how to use xembed with mozilla plugins on X11 platforms.

On non-X11 platforms it's presumably quite a bit more awkward...


*** Note that if you don't want to _embed_ emacs into firefox windows,
just want the ability to type "emacs:filename" into the address bar,
then you can just define an external protocol handler:

Doing it this way is probably not entirely secure...

go to about:config

Following
http://kb.mozillazine.org/Register_protocol#Linux_and_Mac

add the following keys (right click -> new)
Boolean -> network.protocol-handler.external.emacs -> True
String -> network.protocol-handler.app.emacs /path/to/emacs-url-wrapper

after making an emacs-url-wrapper that strips the leading "emacs:" from
its arg e.g. (unsafe)

#!/bin/bash
exec emacs $(echo "$1" | sed 's/emacs://')

Now, emacs:/tmp/blah.txt in the firefox address bar should pop up an
emacs...

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

[David House]

2008/9/4 Paul Michael Reilly <pmr@pajato.com>:
> Steve Yegge, always an interesting read, recently opined that two of
> his "essential" tools are Emacs and Firefox.  And claimed that if one
> were to subsume the other life would be nearly perfect, in at least
> one sense.

Not really what you're asking for, but the conkeror browser was
started by a bunch of Emacsers wishing for a more Emacs-like browser.
It's highly scriptable (in Javascript, not Elisp) and configurable,
and has Emacs-like keybindings. You can use C-i in a textarea to open
an external editing client (like emacsclient). It's still fairly beta
quality at the moment, but is worth checking out:

http://conkeror.org

-- 
-David

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

[T. V. Raman]

Persoanlly I'd prefer the embedding to go in the other direction,
i.e. embed something like Webkit inside Emacs, ask Webki to
render the Web into an emacs buffer, and enable full DOM access
from Emacs Lisp.

This way security sandboxing can be per whatever webkit does, and
emacs which typically runs with more previleges  wouldn't have to
worry about code that comes from the network doing unsafe things.


>>>>> "Paul" == Paul Michael Reilly <pmr@pajato.com> writes:
    Paul> Steve Yegge, always an interesting read, recently
    Paul> opined that two of his "essential" tools are Emacs and
    Paul> Firefox.  And claimed that if one were to subsume the
    Paul> other life would be nearly perfect, in at least one
    Paul> sense.
    Paul> 
    Paul> While there are a few very useful Emacs add-ons that
    Paul> allow you to use emacsclient to edit text in Mozilla
    Paul> based tools (Thunderbird and Firefox come to mind),
    Paul> I've always wondered why someone has not hacked a
    Paul> plugin that support some sort of Emacs url.  For
    Paul> example, "emacs://x.y.z/some/file/or/other.txt" when
    Paul> presented to the browser would fire up a tab on the
    Paul> browser with a full blown Emacs instance
    Paul> "embedded/buried" in it and edit the file other.txt
    Paul> with the full power of Emacs immersed in the browser.
    Paul> Sandbox issues aside, what other issues need to be
    Paul> overcome to create such a browser plugin?
    Paul> 
    Paul> -pmr
    Paul> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

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

[Paul Michael Reilly]

T. V. Raman wrote:
> Persoanlly I'd prefer the embedding to go in the other direction,
> i.e. embed something like Webkit inside Emacs, ask Webki to
> render the Web into an emacs buffer, and enable full DOM access
> from Emacs Lisp.
> 
> This way security sandboxing can be per whatever webkit does, and
> emacs which typically runs with more previleges  wouldn't have to
> worry about code that comes from the network doing unsafe things.

And this approach would appear to have a platform independent nature, 
highly appealing.  I don't know anything about Webkit.  Are you talking 
about adding Webkit to the C level of Emacs, doing an Emacs Lisp binding 
to Webkit (probably running in a separate process or mulitple processes 
ala Chrome) or something else?

-pmr

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

[joakim]

Paul Michael Reilly <pmr@pajato.com> writes:

> T. V. Raman wrote:
>> Persoanlly I'd prefer the embedding to go in the other direction,
>> i.e. embed something like Webkit inside Emacs, ask Webki to
>> render the Web into an emacs buffer, and enable full DOM access
>> from Emacs Lisp.
>>
>> This way security sandboxing can be per whatever webkit does, and
>> emacs which typically runs with more previleges  wouldn't have to
>> worry about code that comes from the network doing unsafe things.
>
> And this approach would appear to have a platform independent nature,
> highly appealing.  I don't know anything about Webkit.  Are you
> talking about adding Webkit to the C level of Emacs, doing an Emacs
> Lisp binding to Webkit (probably running in a separate process or
> mulitple processes ala Chrome) or something else?

It's somewhat possible to do this already. I mailed a patch to
emacs-devel some time ago that lets Emacs embed gtk widgets in a buffer,
like images. (Its very alpha but shows that its possible, at least)

>
> -pmr
>
>
-- 
Joakim Verona

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

[Phil Jackson]

joakim@verona.se writes:

>> And this approach would appear to have a platform independent nature,
>> highly appealing.  I don't know anything about Webkit.  Are you
>> talking about adding Webkit to the C level of Emacs, doing an Emacs
>> Lisp binding to Webkit (probably running in a separate process or
>> mulitple processes ala Chrome) or something else?
>
> It's somewhat possible to do this already. I mailed a patch to
> emacs-devel some time ago that lets Emacs embed gtk widgets in a
> buffer, like images. (Its very alpha but shows that its possible, at
> least)

So, out of interest, how would a Javascript engine (if any) and elisp
co-exist in any sort of harmony?

Cheers,
Phil
-- 
 Philip Jackson
 http://www.shellarchive.co.uk

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

[joakim]

Phil Jackson <phil@shellarchive.co.uk> writes:

> joakim@verona.se writes:
>
>>> And this approach would appear to have a platform independent nature,
>>> highly appealing.  I don't know anything about Webkit.  Are you
>>> talking about adding Webkit to the C level of Emacs, doing an Emacs
>>> Lisp binding to Webkit (probably running in a separate process or
>>> mulitple processes ala Chrome) or something else?
>>
>> It's somewhat possible to do this already. I mailed a patch to
>> emacs-devel some time ago that lets Emacs embed gtk widgets in a
>> buffer, like images. (Its very alpha but shows that its possible, at
>> least)
>
> So, out of interest, how would a Javascript engine (if any) and elisp
> co-exist in any sort of harmony?

I suppose like the existing emacs/mozilla integration, which I forget
the name of, that just pipes js through some sort of port to mozilla and
parses that in elisp. The only difference in this case is that mozilla
would be embedded in an emacs buffer.

> Cheers,
> Phil
-- 
Joakim Verona

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

[Lennart Borgman (gmail)]

joakim@verona.se wrote:
> I suppose like the existing emacs/mozilla integration, which I forget
> the name of, that just pipes js through some sort of port to mozilla and

MozRepl?

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

[Antoine Levitt]

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

Hi,
I fully agree with Paul Reilly and T.V. Raman. I think the last brick that
is remaining to make emacs a full-featured modern desktop is a web browser
(I'm not talking about w3m)
 I have successfully merged yesterday all that remained of my desktop
environment into emacs : IRC and IM. Now, my time is shared among
exclusively emacs and firefox, and the next logical step would be merging
both. What I think would be the ultimate desktop environment would be a way
to have emacs buffers which are web tabs, with a web major mode. It would
use two keyboard maps : one for web surfing, which would we similar to what
conkeror uses, and one for input, which would be the standard one (plus
maybe keys to get out of the input box). I have absolutely no idea of how
feasible this is, but when I saw chrome announcement, first thing that came
to my mind is "hey, these guys start from scratch with a clean API, it may
be easier to wrap into emacs". I hope that some talented hacker (ie not me)
start a project to do this integration. I'd be happy to help, and I suspect
many others too.
2008/9/5 Lennart Borgman (gmail) <lennart.borgman@gmail.com>

> joakim@verona.se wrote:
> > I suppose like the existing emacs/mozilla integration, which I forget
> > the name of, that just pipes js through some sort of port to mozilla and
>
> MozRepl?
>
>
>

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

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

[Richard M. Stallman]

To make Emacs display web pages with their correct appearance is a
gigantic job.  I don't think that linking Emacs with a web browser
display engine is a feasible method.

I proposed years ago that we extend Emacs to the point where it can
function as a word processor.  This is mainly a matter of adding
features that let you put things in a buffer (and save them in files)
to get various kinds of formatting effects.  To display web pages is an
even more distant goal; it requires MORE new buffer and display
features.

I would be very glad to see people start working on some of them.

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

[Antoine Levitt]

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

2008/9/6 Richard M. Stallman <rms@gnu.org>

> To make Emacs display web pages with their correct appearance is a
> gigantic job.  I don't think that linking Emacs with a web browser
> display engine is a feasible method.

Why not ?  See this thread :
http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg00456.html
He already embeds emacs within emacs. Embedding firefox (or chrome, or
midori, or whatever) shouldn't be much harder. A keymap would be transfered
to the underlying process (kinda like what term-mode does), so the user can
scroll the window and thinkgs like that. That alone would be  extremely
useful. Then, we can use inter-process communication (maybe mozrepl can do
that ?) to better communicate with the browser (and really integrate it into
emacs, ie have the minibuffer prompt the user for the webpage to go to, and
maybe add link following, kind of like how conkeror does). What I think
would be really hard to do is have emacs edit text areas in place, but
that's only icing on the cake.


>
> I proposed years ago that we extend Emacs to the point where it can
> function as a word processor.  This is mainly a matter of adding
> features that let you put things in a buffer (and save them in files)
> to get various kinds of formatting effects.  To display web pages is an
> even more distant goal; it requires MORE new buffer and display
> features.
>
> I would be very glad to see people start working on some of them.
>
That's if we want to make emacs itself display the web page. I don't see the
point, since other projects do precisely that.

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

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

[Richard M. Stallman]

    Why not ?  See this thread :
    http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg00456.html
    He already embeds emacs within emacs. Embedding firefox (or chrome, or
    midori, or whatever) shouldn't be much harder.

I have no idea what you mean by "embedding".

    > I would be very glad to see people start working on some of them.
    >
    That's if we want to make emacs itself display the web page.

Yes, exactly.  What else could we be talking about?

If you want to request, from Emacs, the display of some HTML through a
browser, we already have that feature.  We do this by invoking a
separate browser process.  That way is much cleaner.

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

[David Hansen]

On Sat, 06 Sep 2008 17:04:19 -0400 Richard M. Stallman wrote:

>     Why not ?  See this thread :
>     http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg00456.html
>     He already embeds emacs within emacs. Embedding firefox (or chrome, or
>     midori, or whatever) shouldn't be much harder.
>
> I have no idea what you mean by "embedding".

Joakim wrote a patch that allows him to display arbitrary GTK Widgets in
a buffer.  This could either be used to directly link Emacs against the
Gecko or WebKit GTK Widget, or to use the special GTK widget "GtkPlug"
which embeds an application capable of the XEmbed protocol.

>     > I would be very glad to see people start working on some of them.
>     >
>     That's if we want to make emacs itself display the web page.
>
> Yes, exactly.  What else could we be talking about?

Just to give you an idea (OK, that includes the compiled files):

[~/src/WebKit] $ du -hs .
1.3G	.

I'm not quite sure where you want to get the resources to realize such
a huge project.

> If you want to request, from Emacs, the display of some HTML through a
> browser, we already have that feature.  We do this by invoking a
> separate browser process.  That way is much cleaner.

Someone mentioned that it would be really cool to access all the DOM
stuff from Emacs Lisp.  I have to admit that this would be pretty
appealing (though I'm not sure if it's really worth the work).

You could write nice filter for the web, e.g. remove ads, filter cookies
or change images of your president to "hello.jpg".

David

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

[Lennart Borgman (gmail)]

David Hansen wrote:
> Someone mentioned that it would be really cool to access all the DOM
> stuff from Emacs Lisp.  I have to admit that this would be pretty
> appealing (though I'm not sure if it's really worth the work).

Is perhaps that possible using MozRepl? I am not sure how embedding
actually add something in this respect, but I might be wrong.

> You could write nice filter for the web, e.g. remove ads, filter cookies
> or change images of your president to "hello.jpg".
> 
> David
> 
> 
> 
> 

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

[David Hansen]

On Sat, 06 Sep 2008 23:49:14 +0200 Lennart Borgman wrote:

> David Hansen wrote:
>> Someone mentioned that it would be really cool to access all the DOM
>> stuff from Emacs Lisp.  I have to admit that this would be pretty
>> appealing (though I'm not sure if it's really worth the work).
>
> Is perhaps that possible using MozRepl? I am not sure how embedding
> actually add something in this respect, but I might be wrong.

That would be JS and not Lisp.  Not that much fun.

David

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

[Lennart Borgman (gmail)]

David Hansen wrote:
> On Sat, 06 Sep 2008 23:49:14 +0200 Lennart Borgman wrote:
> 
>> David Hansen wrote:
>>> Someone mentioned that it would be really cool to access all the DOM
>>> stuff from Emacs Lisp.  I have to admit that this would be pretty
>>> appealing (though I'm not sure if it's really worth the work).
>> Is perhaps that possible using MozRepl? I am not sure how embedding
>> actually add something in this respect, but I might be wrong.
> 
> That would be JS and not Lisp.  Not that much fun.


But somewhere the conversion still have to be made. Could not that
conversion be done using MozRepl as connector so to say?

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

[David Hansen]

On Sun, 07 Sep 2008 00:48:10 +0200 Lennart Borgman wrote:

> David Hansen wrote:
>> On Sat, 06 Sep 2008 23:49:14 +0200 Lennart Borgman wrote:
>> 
>>> David Hansen wrote:
>>>> Someone mentioned that it would be really cool to access all the DOM
>>>> stuff from Emacs Lisp.  I have to admit that this would be pretty
>>>> appealing (though I'm not sure if it's really worth the work).
>>> Is perhaps that possible using MozRepl? I am not sure how embedding
>>> actually add something in this respect, but I might be wrong.
>> 
>> That would be JS and not Lisp.  Not that much fun.
>
> But somewhere the conversion still have to be made. Could not that
> conversion be done using MozRepl as connector so to say?

There are experimental GObject bindings for the WebKit DOM.  It
shouldn't be to hard to have a new Lisp type "GObject".

As a free gift we could then as well write arbitrary GTK apps in Elisp.
Which would be quite awesome combined with Joakims work.

David

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

[Sean O'Rourke]

David Hansen <david.hansen@gmx.net> writes:

> On Sat, 06 Sep 2008 17:04:19 -0400 Richard M. Stallman wrote:
>>     That's if we want to make emacs itself display the web page.
>>
>> Yes, exactly.  What else could we be talking about?
>
> Just to give you an idea (OK, that includes the compiled files):
>
> [~/src/WebKit] $ du -hs .
> 1.3G	.
>
> I'm not quite sure where you want to get the resources to realize such
> a huge project.

And it's actually much worse than that.  As far as I can tell, de
facto web standards change quickly and are defined by whatever
the main browsers (IE, Firefox derivatives, Webkit derivatives)
support.  I still prefer a deeply-integrated Emacs browser
(emacs-w3m) for many tasks, but there's just no way Emacs can
keep up with these standards.

I'm not sure if I *want* Emacs to become a web browser (just
making it easy to edit the contents of text boxes on all
platforms using Emacs, via emacsclient or otherwise, would be
plenty), but even if I did want it to, I doubt it could become
one.

Sean

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

[Richard M. Stallman]

    Joakim wrote a patch that allows him to display arbitrary GTK Widgets in
    a buffer.

That is a useful feature because it could be used to implement various
GTK-style interfaces for Emacs package.

	       This could either be used to directly link Emacs against the
    Gecko or WebKit GTK Widget, or to use the special GTK widget "GtkPlug"
    which embeds an application capable of the XEmbed protocol.

For modularity's sake, it is much cleaner to run the browser in a
separate process and have it display thru GtkPlug.  To link Emacs with
Gecko or Webkit would be a lot of extra trouble, and the trouble would
go on and on.

    Someone mentioned that it would be really cool to access all the DOM
    stuff from Emacs Lisp.

What uses would this be good for, if it existed?

    You could write nice filter for the web, e.g. remove ads, filter cookies
    or change images of your president to "hello.jpg".

If what you want is extensibility in Lisp for your web browser, I
think it is better to interface Guile (rather than Emacs) to the
browser.  Emacs is not just Lisp, it is certain model of textual data.
Web browsers have a different model of textual data, and trying to
glue them together would produce a gross kludge.

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

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

> I proposed years ago that we extend Emacs to the point where it can
> function as a word processor.  This is mainly a matter of adding
> features that let you put things in a buffer (and save them in files)
> to get various kinds of formatting effects.  To display web pages is
> an even more distant goal; it requires MORE new buffer and display
> features.

That's assuming we rely on the Emacs redisplay engine.  The approach
being discussed in this thread is to embedding the output generated by
an external browser library in an Emacs window.

Basically, this involves being able to tell an Emacs window not to draw
the usual Emacs display, but to display the output from an external
process (an embedded browser process) instead.  I think it's very
feasible, assuming someone has the time to do it.  The bottleneck here
is manpower.

(Maybe this would be a good Google Summer of Code project).

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

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> I proposed years ago that we extend Emacs to the point where it can
>> function as a word processor.  This is mainly a matter of adding
>> features that let you put things in a buffer (and save them in files)
>> to get various kinds of formatting effects.  To display web pages is
>> an even more distant goal; it requires MORE new buffer and display
>> features.
>
> That's assuming we rely on the Emacs redisplay engine.  The approach
> being discussed in this thread is to embedding the output generated by
> an external browser library in an Emacs window.
>
> Basically, this involves being able to tell an Emacs window not to draw
> the usual Emacs display, but to display the output from an external
> process (an embedded browser process) instead.  I think it's very
> feasible, assuming someone has the time to do it.  The bottleneck here
> is manpower.

Again I want to shamelessly promote my project:

http://www.emacswiki.org/cgi-bin/wiki/EmacsXembed

I havent worked on it lately, but this thread is starting to make me
want to prove that its possible to embed a browser.

The thing that actually stopped me from demoing browser embedding,
rather that video etc, is that I didnt find a browser which supported
being embedded with xembed. It shouldnt be a big problem, though, to
modify a gnome based browser to use a xembeddable widget as main
window.

My primary aim for embedding isnt actually browsers: its for embedding
stuff like Inkscape, multimedia apps, and make music guis for csound and
supercollider etc, so thats why I havent done anything more for browser
support.

> (Maybe this would be a good Google Summer of Code project).
-- 
Joakim Verona

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

[Chong Yidong]

joakim@verona.se writes:

> Again I want to shamelessly promote my project:
>
> http://www.emacswiki.org/cgi-bin/wiki/EmacsXembed
>
> I havent worked on it lately, but this thread is starting to make me
> want to prove that its possible to embed a browser.
>
> The thing that actually stopped me from demoing browser embedding,
> rather that video etc, is that I didnt find a browser which supported
> being embedded with xembed. It shouldnt be a big problem, though, to
> modify a gnome based browser to use a xembeddable widget as main
> window.

I haven't had time to look at your code, but if you already got embedded
GTK applications to work, it might be possible to use GtkMozEmbed:

http://www.mozilla.org/unix/gtk-embedding.html

The main problem is that their documentation looks pretty sketchy.

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

[David Hansen]

On Sat, 06 Sep 2008 18:58:48 +0200 joakim@verona.se wrote:

> The thing that actually stopped me from demoing browser embedding,
> rather that video etc, is that I didnt find a browser which supported
> being embedded with xembed. It shouldnt be a big problem, though, to
> modify a gnome based browser to use a xembeddable widget as main
> window.

Not tested, but it's about that easy:

#include <gtk/gtk.h>
#include <webkit/webkit.h>

#define URI "http://www.gnu.org/"

int
main (int argc, gchar **argv)
{
  GtkWidget *plug, *scroll, *webview;

  gtk_init (&argc, &argv);

  plug    = gtk_plug_new (0);
  scroll  = gtk_scrolled_window_new (NULL, NULL);
  webview = webkit_web_view_new ();

  gtk_container_add (GTK_CONTAINER (plug)  , scroll);
  gtk_container_add (GTK_CONTAINER (scroll), webview);

  gtk_widget_show_all (plug);
  webkit_web_view_open (WEBKIT_WEB_VIEW (webview), URI);

  gtk_main ();

  return 0;
}

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

[T. V. Raman]

I think this would make an excellent Google Summer Of Code
project if we can find the right  people to do the project. Do
you have someone in mind?

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:
    Chong> "Richard M. Stallman" <rms@gnu.org> writes:
    >> I proposed years ago that we extend Emacs to the point
    >> where it can function as a word processor.  This is mainly
    >> a matter of adding features that let you put things in a
    >> buffer (and save them in files) to get various kinds of
    >> formatting effects.  To display web pages is an even more
    >> distant goal; it requires MORE new buffer and display
    >> features.
    Chong> 
    Chong> That's assuming we rely on the Emacs redisplay engine.
    Chong> The approach being discussed in this thread is to
    Chong> embedding the output generated by an external browser
    Chong> library in an Emacs window.
    Chong> 
    Chong> Basically, this involves being able to tell an Emacs
    Chong> window not to draw the usual Emacs display, but to
    Chong> display the output from an external process (an
    Chong> embedded browser process) instead.  I think it's very
    Chong> feasible, assuming someone has the time to do it.  The
    Chong> bottleneck here is manpower.
    Chong> 
    Chong> (Maybe this would be a good Google Summer of Code
    Chong> project).

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

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

[Stefan Monnier]

> To make Emacs display web pages with their correct appearance is a
> gigantic job.  I don't think that linking Emacs with a web browser
> display engine is a feasible method.

On the contrary, I think it's a very good direction.  Hopefully, we can
do that with a browser (or rendering engine) that might be interesting
in participating in this effort, so that we can get them to help us
better intergrate the two tools (e.g. integrate Firefox's display in an
Emacs window, but then let Firefox use Emacs windows for its
text-editing widgets).

> I proposed years ago that we extend Emacs to the point where it can
> function as a word processor.

It never struck me as an interesting goal: for one, we already have
latex-mode for that (i.e. Emacs is the only tool I use for word
processing, even more so now that I can display the resulting PDF with
doc-view-mode), and in any case we already have plenty to do in order to
make Emacs the best text editor there is.

> This is mainly a matter of adding features that let you put things in
> a buffer (and save them in files) to get various kinds of formatting
> effects.  To display web pages is an even more distant goal; it
> requires MORE new buffer and display features.

I think that efforts along the lines of what W3 tried to do would be
a waste of time.  Better try to reuse other people's efforts trying to
write good HTML rendering engines than try and come up with our own,
especially since it's a very difficult project in itself.


        Stefan

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

[Richard M. Stallman]

    > I proposed years ago that we extend Emacs to the point where it can
    > function as a word processor.

    It never struck me as an interesting goal: for one, we already have
    latex-mode for that (i.e. Emacs is the only tool I use for word
    processing, even more so now that I can display the resulting PDF with
    doc-view-mode),

It sounds like you are editing text with markup commands and viewing
the formatted results on the side.  Of course that works, but most
people prefer a word processor in which one edits the formatted text.
I proposed adding that capability to Emacs so that it would work in
the mode people generally want.

It looks like you are proposing a new feature which consists of
editing HTML and viewng the formatted results on the side.  Is that
correct?

It did not occur to me that that is what people were talking about,
because it doesn't seem like much of an advance.  If we want it, the
clean and simple implemenation is to run the browser in a separate
process.  It could do the display in a window provided by Emacs, or in
its own window.

Perhaps it could render the HTML into PDF and Emacs could display that.

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

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
> Perhaps it could render the HTML into PDF and Emacs could display that.

It depends on the purpose, but if you are interested in correct
rendering then there is probably no other way then to let a web browser
render it (since it is so complicated to render it correctly).

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

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

> It looks like you are proposing a new feature which consists of
> editing HTML and viewng the formatted results on the side.  Is that
> correct?
>
> It did not occur to me that that is what people were talking about,
> because it doesn't seem like much of an advance.  If we want it, the
> clean and simple implemenation is to run the browser in a separate
> process.  It could do the display in a window provided by Emacs, or in
> its own window.

I think the main point is that nowadays people use the web a *lot*.
Personally, the time I spend using a web browser is several orders of
magnitude more than the time I spend using a word processor.

Switching constantly between Emacs and Firefox (e.g., by making Emacs
open links via a separate Firefox application) is inefficient.  By
analogy, we provide comint interfaces between Emacs and programs like
gdb, so that people can continue using those external programs while
staying in the Emacs environment.

The difference here is that the relevant output of programs like gdb is
text, while the relevant output of a web browser is an interactive
graphical display.  (Note the "interactive" part, which is why
approaches like rendering into PDF aren't very useful.)  Thus, to answer
your original question, "embedding" means delegating the contents of an
Emacs window (or part of an Emacs window) to a web browser process, such
as Mozilla Gecko or Webkit.

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

[Richard M. Stallman]

    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?
Or do you mean process-switching, something done by the kernel?

In what sense is it inefficient?

      Thus, to answer
    your original question, "embedding" means delegating the contents of an
    Emacs window (or part of an Emacs window) to a web browser process, such
    as Mozilla Gecko or Webkit.

To delegate display to a web browser process would normlly mean running
a browser rather than running just part of one.

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

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> 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.

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

[Antoine Levitt]

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

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.
2008/9/8 Chong Yidong <cyd@stupidchicken.com>

> "Richard M. Stallman" <rms@gnu.org> 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.
>

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

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

[Thomas Lord]

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 <cyd@stupidchicken.com 
> <mailto:cyd@stupidchicken.com>>
>
>     "Richard M. Stallman" <rms@gnu.org <mailto:rms@gnu.org>> 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.
>
>

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

[Antoine Levitt]

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

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

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

[Stefan Monnier]

> Emacs has the concept that two windows can look at the same buffer.

This is a general problem for the XEmbed thingy, whether it displays
a browser or something else.  There are various ways to punt on the
problem: only draw in one of the two windows put a grey rectangle in the
other, or do a vnc-style "let's copy the pixmap pof the first onto the
other, so even if there's only one active, the other is at least
displayed right".

But it doesn't matter that much in practice: people will just have to
live with the limitation, but it doesn't make the idea unusable.  
You won't get some of the power you usually expect from Emacs, but then
again, you never had this power in Firefox anyway, so it's not like you
lost anything.


        Stefan

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

[joakim]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Emacs has the concept that two windows can look at the same buffer.
>
> This is a general problem for the XEmbed thingy, whether it displays
> a browser or something else.  There are various ways to punt on the
> problem: only draw in one of the two windows put a grey rectangle in the
> other, or do a vnc-style "let's copy the pixmap pof the first onto the
> other, so even if there's only one active, the other is at least
> displayed right".

My patch currently does the "grey rectangle" variant.
This is not so bad as it might appear, at least for the use-cases I'm
interested in, which is buffers with many gtk widgets, many views on
the buffers, but not necesarily the same part in each view.

I agree that usability with multiple views on a buffer with a large
xembed widget would be a quite unstellar experience, at least with my patch.


> But it doesn't matter that much in practice: people will just have to
> live with the limitation, but it doesn't make the idea unusable.  
> You won't get some of the power you usually expect from Emacs, but then
> again, you never had this power in Firefox anyway, so it's not like you
> lost anything.
>
>
>         Stefan
-- 
Joakim Verona

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

[Thomas Lord]

Stefan Monnier wrote:
>> Emacs has the concept that two windows can look at the same buffer.
>>     
> [....]
>
> But it doesn't matter that much in practice: people will just have to
> live with the limitation, but it doesn't make the idea unusable.  
>   

I didn't mean to claim otherwise.

It will be, as RMS put it, a kludge (and a pandora's box of hassles).

It won't succeed at seamlessly integrating browser windows into Emacs
window management from a user perspective (so it fails at the goal -- i.e.,
won't work).

In all seriousness, people interested in that vision of the future
that includes things like browsing but with Emacs-style windows
might want to work not on the problem of how to embed stuff
in Emacs but on the problems of how to have multiple views
of a single web page.



> You won't get some of the power you usually expect from Emacs, but then
> again, you never had this power in Firefox anyway, so it's not like you
> lost anything.
>   

Certainly but RMS is right when he describes it as a kludge
and likely an endless source of problems (because when a thing
doesn't and can't ever work "quite right" there is a constant
pressure to "fix" it, no matter how many times it has been
"fixed" before).

-t


>
>         Stefan
>
>   

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

[Richard M. Stallman]

    Emacs has the concept that two windows can look at the same
    buffer.

Displaying a buffer containing an XEmbed in two Emacs windows ought to
work work -- perhaps only because it would not mean what one might
expect.

Suppose you put an XEmbed widget into an Emacs buffer (perhaps with a
special kind of `display' property on part of the text) and display
the buffer in a window.  As with any other thing in the Emacs buffer,
Emacs has to know how tall it should appear.  You would have to
specify this, in the `display' property I suppose.  Then when Emacs
displays that buffer in the window, it will show part of the XEmbed if
appropriate, just as it might show all or part of an image in the
buffer.

It should not be hard for Emacs to do this in two windows in parallel,
if it can make the other program display into a pixmap of the
specified size.

Note that scrolling an Emacs window will not tell the other program
anything.  It will just tell Emacs to display a different part of the
appearance of the buffer in that window.

I think that people have a different behavior in mind for the browser:
namely to hand over a particular Emacs window to the browser and
expecting it to use the whole of that window, knowing the size of that
window.

That would be a different kind of feature.  Instead of having an
XEmbed widget in the text in a buffer, it would mean having a buffer
that is simply an alias for displaying the output of another program.
So if you tell an Emacs window to display that buffer, it really means
to telling the other program to use and control that Emacs window.

It would be hard to do that in more than one window, unless the other
program supports multiple windows.  If it does, it ought to be able to
handle two Emacs windows in parallel the same way it would handle two
other windows in parallel.  Most graphical browsers seem to be able to
do this.

Another way to handle doing this in two windows at once is to run two
copies of the program in parallel.  That might be ok for some simple
programs.

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

[Richard M. Stallman]

    > When you say "switching", what does that refer to?
    > Are you talking about a UI-level operation?

    Yes.

Now I am starting to understand what this is about.  Could you say
more precisely what "switching" means, in UI terms, and what a UI
without "switching" might look like?

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

[Stefan Monnier]

>> I proposed years ago that we extend Emacs to the point where it can
>> function as a word processor.

>     It never struck me as an interesting goal: for one, we already have
>     latex-mode for that (i.e. Emacs is the only tool I use for word
>     processing, even more so now that I can display the resulting PDF with
>     doc-view-mode),

> It sounds like you are editing text with markup commands and viewing
> the formatted results on the side.  Of course that works, but most
> people prefer a word processor in which one edits the formatted text.

Maybe most people do, but I'm not sure if most Emacs users do.

> I proposed adding that capability to Emacs so that it would work in
> the mode people generally want.

But even in the event that most Emacs users do, I don't think that
turning Emacs into a WYSIWYG word processor is a good idea.  This said,
I do not intend to spend anny more time talking about it, unless someone
actully starts working on such a project (at which point I'll try and
convince him to work on something more likely to be useful).

> It looks like you are proposing a new feature which consists of
> editing HTML and viewng the formatted results on the side.  Is that
> correct?

No, I'm not suggesting any new feature, other than the fact that using
something like XEmbed to let something like Firefox render web pages is
a more promising direction than doing the whole rendering in Emacs.


        Stefan

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

[Richard M. Stallman]

    > It sounds like you are editing text with markup commands and viewing
    > the formatted results on the side.  Of course that works, but most
    > people prefer a word processor in which one edits the formatted text.

    Maybe most people do, but I'm not sure if most Emacs users do.

The aim is to make Emacs appeal to people that want to edit formatted
documents through word processing.  The existing users of Emacs who
like the current modes of operation could continue to use them.

Making Emacs a word processor is a matter of implementing additional
formatting features: representing them in the buffer, displaying them,
and saving them in files.

    No, I'm not suggesting any new feature, other than the fact that using
    something like XEmbed to let something like Firefox render web pages is
    a more promising direction than doing the whole rendering in Emacs.

I agree with you on that point.

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

[T. V. Raman]

I'd leave the JavaScript engine completely on the Web browser
side, wouldn't let it perform *any* operations to Emacs (reason:
security).

I'd enable Emacs Lisp access to JavaScript, perhaps via a socket,
and allow lisp programs to generate and send javascript down that
socket. Incidentally I already do the latter with Firefox and an
extension called mozrepl.

>>>>> "Phil" == Phil Jackson <phil@shellarchive.co.uk> writes:
    Phil> joakim@verona.se writes:
    >>> And this approach would appear to have a platform
    >>> independent nature, highly appealing.  I don't know
    >>> anything about Webkit.  Are you talking about adding
    >>> Webkit to the C level of Emacs, doing an Emacs Lisp
    >>> binding to Webkit (probably running in a separate process
    >>> or mulitple processes ala Chrome) or something else?
    >> 
    >> It's somewhat possible to do this already. I mailed a
    >> patch to emacs-devel some time ago that lets Emacs embed
    >> gtk widgets in a buffer, like images. (Its very alpha but
    >> shows that its possible, at least)
    Phil> 
    Phil> So, out of interest, how would a Javascript engine (if
    Phil> any) and elisp co-exist in any sort of harmony?
    Phil> 
    Phil> Cheers, Phil -- Philip Jackson
    Phil> http://www.shellarchive.co.uk

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

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

[T. V. Raman]

>>>>> "Paul" == Paul Michael Reilly <pmr@pajato.com> writes:
    Paul> T. V. Raman wrote:
    >> Persoanlly I'd prefer the embedding to go in the other
    >> direction, i.e. embed something like Webkit inside Emacs,
    >> ask Webki to render the Web into an emacs buffer, and
    >> enable full DOM access from Emacs Lisp.
    >> 
    >> This way security sandboxing can be per whatever webkit
    >> does, and emacs which typically runs with more previleges
    >> wouldn't have to worry about code that comes from the
    >> network doing unsafe things.
    Paul> 
    Paul> And this approach would appear to have a platform
    Paul> independent nature, highly appealing.  I don't know
    Paul> anything about Webkit.  Are you talking about adding
    Paul> Webkit to the C level of Emacs, doing an Emacs Lisp

Linking in Webkit at the C level, possibly as a shared library.
    Paul> binding to Webkit (probably running in a separate
Webkit should run in a separate process, I'd go so far as to run
a separate, new process for each Emacs buffer that one associates
with the Web. So  putting a buffer in web-mode would
automatically have that buffer talking to a fresh webkit process,
a la tabs in Chrome.

    Paul> process or mulitple processes ala Chrome) or something
    Paul> else?
    Paul> 

If you search for Webkit and Emacs, someone out there has
apparently succeeded in doing a very early pass at this via the
GTK binding for Emacs. But for such a binding to be truly
valuable from the emacs side, ie more than screen-dep, we would
also need Lisp access to the DOM.
    Paul> -pmr
    Paul> 
    Paul> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

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

[Christian Faulhammer]

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

Hi,

"T. V. Raman" <raman@users.sf.net>:

> Persoanlly I'd prefer the embedding to go in the other direction,
> i.e. embed something like Webkit inside Emacs, ask Webki to
> render the Web into an emacs buffer, and enable full DOM access
> from Emacs Lisp.

 I'd like to AOL that...sounds really interesting.  Not necessarily
Webkit, there is Gecko, too.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]