* An Emacs plug-in for a browser (Firefox?) @ 2008-09-04 22:18 Paul Michael Reilly 2008-09-05 0:16 ` David De La Harpe Golden ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Paul Michael Reilly @ 2008-09-04 22:18 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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 2 siblings, 0 replies; 45+ messages in thread From: David De La Harpe Golden @ 2008-09-05 0:16 UTC (permalink / raw To: pmr; +Cc: emacs-devel 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... ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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 2 siblings, 0 replies; 45+ messages in thread From: David House @ 2008-09-05 0:19 UTC (permalink / raw To: pmr; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* An Emacs plug-in for a browser (Firefox?) 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 20:40 ` Christian Faulhammer 2 siblings, 2 replies; 45+ messages in thread From: T. V. Raman @ 2008-09-05 2:42 UTC (permalink / raw To: pmr; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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 13:32 ` T. V. Raman 2008-09-05 20:40 ` Christian Faulhammer 1 sibling, 2 replies; 45+ messages in thread From: Paul Michael Reilly @ 2008-09-05 4:53 UTC (permalink / raw To: raman; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 4:53 ` Paul Michael Reilly @ 2008-09-05 6:44 ` joakim 2008-09-05 8:53 ` Phil Jackson 2008-09-05 13:32 ` T. V. Raman 1 sibling, 1 reply; 45+ messages in thread From: joakim @ 2008-09-05 6:44 UTC (permalink / raw To: Paul Michael Reilly; +Cc: emacs-devel, raman 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 6:44 ` joakim @ 2008-09-05 8:53 ` Phil Jackson 2008-09-05 9:21 ` joakim 2008-09-05 13:33 ` T. V. Raman 0 siblings, 2 replies; 45+ messages in thread From: Phil Jackson @ 2008-09-05 8:53 UTC (permalink / raw To: joakim; +Cc: Paul Michael Reilly, raman, emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 8:53 ` Phil Jackson @ 2008-09-05 9:21 ` joakim 2008-09-05 9:30 ` Lennart Borgman (gmail) 2008-09-05 13:33 ` T. V. Raman 1 sibling, 1 reply; 45+ messages in thread From: joakim @ 2008-09-05 9:21 UTC (permalink / raw To: Phil Jackson; +Cc: Paul Michael Reilly, raman, emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 9:21 ` joakim @ 2008-09-05 9:30 ` Lennart Borgman (gmail) 2008-09-05 11:20 ` Antoine Levitt 0 siblings, 1 reply; 45+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-05 9:30 UTC (permalink / raw To: joakim; +Cc: Paul Michael Reilly, emacs-devel, Phil Jackson, raman 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 9:30 ` Lennart Borgman (gmail) @ 2008-09-05 11:20 ` Antoine Levitt 2008-09-06 7:12 ` Richard M. Stallman 0 siblings, 1 reply; 45+ messages in thread From: Antoine Levitt @ 2008-09-05 11:20 UTC (permalink / raw To: Lennart Borgman (gmail) Cc: Paul Michael Reilly, raman, Phil Jackson, joakim, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 11:20 ` Antoine Levitt @ 2008-09-06 7:12 ` Richard M. Stallman 2008-09-06 10:48 ` Antoine Levitt ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Richard M. Stallman @ 2008-09-06 7:12 UTC (permalink / raw To: Antoine Levitt; +Cc: pmr, lennart.borgman, joakim, emacs-devel, raman, phil 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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 16:42 ` Chong Yidong 2008-09-06 20:11 ` Stefan Monnier 2 siblings, 1 reply; 45+ messages in thread From: Antoine Levitt @ 2008-09-06 10:48 UTC (permalink / raw To: rms; +Cc: pmr, lennart.borgman, joakim, emacs-devel, raman, phil [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 10:48 ` Antoine Levitt @ 2008-09-06 21:04 ` Richard M. Stallman 2008-09-06 21:36 ` David Hansen 0 siblings, 1 reply; 45+ messages in thread From: Richard M. Stallman @ 2008-09-06 21:04 UTC (permalink / raw To: Antoine Levitt; +Cc: pmr, lennart.borgman, joakim, raman, emacs-devel, phil 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 21:04 ` Richard M. Stallman @ 2008-09-06 21:36 ` David Hansen 2008-09-06 21:49 ` Lennart Borgman (gmail) ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: David Hansen @ 2008-09-06 21:36 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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:41 ` Sean O'Rourke 2008-09-07 23:36 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-06 21:49 UTC (permalink / raw To: emacs-devel 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 > > > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 21:49 ` Lennart Borgman (gmail) @ 2008-09-06 22:25 ` David Hansen 2008-09-06 22:48 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 45+ messages in thread From: David Hansen @ 2008-09-06 22:25 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 22:25 ` David Hansen @ 2008-09-06 22:48 ` Lennart Borgman (gmail) 2008-09-06 23:08 ` David Hansen 0 siblings, 1 reply; 45+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-06 22:48 UTC (permalink / raw To: emacs-devel 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 22:48 ` Lennart Borgman (gmail) @ 2008-09-06 23:08 ` David Hansen 0 siblings, 0 replies; 45+ messages in thread From: David Hansen @ 2008-09-06 23:08 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 21:36 ` David Hansen 2008-09-06 21:49 ` Lennart Borgman (gmail) @ 2008-09-06 22:41 ` Sean O'Rourke 2008-09-07 23:36 ` Richard M. Stallman 2 siblings, 0 replies; 45+ messages in thread From: Sean O'Rourke @ 2008-09-06 22:41 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 21:36 ` David Hansen 2008-09-06 21:49 ` Lennart Borgman (gmail) 2008-09-06 22:41 ` Sean O'Rourke @ 2008-09-07 23:36 ` Richard M. Stallman 2 siblings, 0 replies; 45+ messages in thread From: Richard M. Stallman @ 2008-09-07 23:36 UTC (permalink / raw To: David Hansen; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 7:12 ` Richard M. Stallman 2008-09-06 10:48 ` Antoine Levitt @ 2008-09-06 16:42 ` Chong Yidong 2008-09-06 16:58 ` joakim 2008-09-06 21:54 ` T. V. Raman 2008-09-06 20:11 ` Stefan Monnier 2 siblings, 2 replies; 45+ messages in thread From: Chong Yidong @ 2008-09-06 16:42 UTC (permalink / raw To: rms; +Cc: pmr, lennart.borgman, joakim, raman, Antoine Levitt, emacs-devel, phil "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). ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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 1 sibling, 2 replies; 45+ messages in thread From: joakim @ 2008-09-06 16:58 UTC (permalink / raw To: Chong Yidong Cc: rms, pmr, lennart.borgman, Antoine Levitt, raman, emacs-devel, phil 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 16:58 ` joakim @ 2008-09-06 19:42 ` Chong Yidong 2008-09-06 20:20 ` David Hansen 1 sibling, 0 replies; 45+ messages in thread From: Chong Yidong @ 2008-09-06 19:42 UTC (permalink / raw To: joakim; +Cc: rms, pmr, lennart.borgman, Antoine Levitt, raman, emacs-devel, phil 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 16:58 ` joakim 2008-09-06 19:42 ` Chong Yidong @ 2008-09-06 20:20 ` David Hansen 1 sibling, 0 replies; 45+ messages in thread From: David Hansen @ 2008-09-06 20:20 UTC (permalink / raw To: emacs-devel 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; } ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 16:42 ` Chong Yidong 2008-09-06 16:58 ` joakim @ 2008-09-06 21:54 ` T. V. Raman 1 sibling, 0 replies; 45+ messages in thread From: T. V. Raman @ 2008-09-06 21:54 UTC (permalink / raw To: cyd; +Cc: rms, pmr, lennart.borgman, joakim, emacs-devel, smeuuh, raman, phil 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 7:12 ` Richard M. Stallman 2008-09-06 10:48 ` Antoine Levitt 2008-09-06 16:42 ` Chong Yidong @ 2008-09-06 20:11 ` Stefan Monnier 2008-09-07 17:39 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Stefan Monnier @ 2008-09-06 20:11 UTC (permalink / raw To: rms; +Cc: pmr, lennart.borgman, joakim, raman, Antoine Levitt, emacs-devel, phil > 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-06 20:11 ` Stefan Monnier @ 2008-09-07 17:39 ` Richard M. Stallman 2008-09-07 17:49 ` Lennart Borgman (gmail) ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Richard M. Stallman @ 2008-09-07 17:39 UTC (permalink / raw To: Stefan Monnier Cc: pmr, lennart.borgman, smeuuh, emacs-devel, joakim, raman, phil > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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-07 19:55 ` Stefan Monnier 2 siblings, 0 replies; 45+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-07 17:49 UTC (permalink / raw To: rms; +Cc: pmr, joakim, smeuuh, emacs-devel, Stefan Monnier, raman, phil 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). ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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-07 19:55 ` Stefan Monnier 2 siblings, 1 reply; 45+ messages in thread From: Chong Yidong @ 2008-09-07 18:29 UTC (permalink / raw To: rms Cc: pmr, lennart.borgman, joakim, emacs-devel, Stefan Monnier, smeuuh, raman, phil "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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-07 18:29 ` Chong Yidong @ 2008-09-08 9:22 ` Richard M. Stallman 2008-09-08 12:31 ` Chong Yidong 0 siblings, 1 reply; 45+ messages in thread From: Richard M. Stallman @ 2008-09-08 9:22 UTC (permalink / raw To: Chong Yidong Cc: pmr, lennart.borgman, joakim, smeuuh, emacs-devel, monnier, raman, phil 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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 22:13 ` Richard M. Stallman 0 siblings, 2 replies; 45+ messages in thread From: Chong Yidong @ 2008-09-08 12:31 UTC (permalink / raw To: rms; +Cc: pmr, lennart.borgman, joakim, smeuuh, emacs-devel, monnier, raman, phil "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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 12:31 ` Chong Yidong @ 2008-09-08 17:07 ` Antoine Levitt 2008-09-08 19:05 ` Thomas Lord 2008-09-08 22:13 ` Richard M. Stallman 1 sibling, 1 reply; 45+ messages in thread From: Antoine Levitt @ 2008-09-08 17:07 UTC (permalink / raw To: Chong Yidong Cc: rms, pmr, lennart.borgman, joakim, emacs-devel, monnier, raman, phil [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 17:07 ` Antoine Levitt @ 2008-09-08 19:05 ` Thomas Lord 2008-09-08 19:07 ` Antoine Levitt ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Thomas Lord @ 2008-09-08 19:05 UTC (permalink / raw To: Antoine Levitt Cc: rms, pmr, Chong Yidong, lennart.borgman, joakim, emacs-devel, monnier, raman, phil 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. > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 19:05 ` Thomas Lord @ 2008-09-08 19:07 ` Antoine Levitt 2008-09-08 20:27 ` Thomas Lord 2008-09-08 20:34 ` Stefan Monnier 2008-09-09 8:11 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Antoine Levitt @ 2008-09-08 19:07 UTC (permalink / raw To: Thomas Lord Cc: rms, pmr, Chong Yidong, lennart.borgman, joakim, emacs-devel, monnier, raman, phil [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 19:07 ` Antoine Levitt @ 2008-09-08 20:27 ` Thomas Lord 0 siblings, 0 replies; 45+ messages in thread From: Thomas Lord @ 2008-09-08 20:27 UTC (permalink / raw To: Antoine Levitt Cc: rms, pmr, Chong Yidong, lennart.borgman, joakim, emacs-devel, monnier, raman, phil 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 > > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 19:05 ` Thomas Lord 2008-09-08 19:07 ` Antoine Levitt @ 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 2 siblings, 2 replies; 45+ messages in thread From: Stefan Monnier @ 2008-09-08 20:34 UTC (permalink / raw To: Thomas Lord Cc: rms, pmr, Chong Yidong, lennart.borgman, joakim, emacs-devel, Antoine Levitt, raman, phil > 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 20:34 ` Stefan Monnier @ 2008-09-08 21:33 ` joakim 2008-09-08 21:46 ` Thomas Lord 1 sibling, 0 replies; 45+ messages in thread From: joakim @ 2008-09-08 21:33 UTC (permalink / raw To: Stefan Monnier Cc: Thomas Lord, rms, pmr, Chong Yidong, lennart.borgman, Antoine Levitt, emacs-devel, raman, phil 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 20:34 ` Stefan Monnier 2008-09-08 21:33 ` joakim @ 2008-09-08 21:46 ` Thomas Lord 1 sibling, 0 replies; 45+ messages in thread From: Thomas Lord @ 2008-09-08 21:46 UTC (permalink / raw To: Stefan Monnier Cc: rms, pmr, Chong Yidong, lennart.borgman, joakim, emacs-devel, Antoine Levitt, raman, phil 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 > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 19:05 ` Thomas Lord 2008-09-08 19:07 ` Antoine Levitt 2008-09-08 20:34 ` Stefan Monnier @ 2008-09-09 8:11 ` Richard M. Stallman 2 siblings, 0 replies; 45+ messages in thread From: Richard M. Stallman @ 2008-09-09 8:11 UTC (permalink / raw To: Thomas Lord Cc: pmr, cyd, lennart.borgman, joakim, emacs-devel, smeuuh, raman, phil, monnier 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-08 12:31 ` Chong Yidong 2008-09-08 17:07 ` Antoine Levitt @ 2008-09-08 22:13 ` Richard M. Stallman 1 sibling, 0 replies; 45+ messages in thread From: Richard M. Stallman @ 2008-09-08 22:13 UTC (permalink / raw To: Chong Yidong Cc: pmr, lennart.borgman, joakim, smeuuh, emacs-devel, monnier, raman, phil > 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 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-07 19:55 ` Stefan Monnier 2008-09-08 9:22 ` Richard M. Stallman 2 siblings, 1 reply; 45+ messages in thread From: Stefan Monnier @ 2008-09-07 19:55 UTC (permalink / raw To: rms; +Cc: pmr, lennart.borgman, smeuuh, emacs-devel, joakim, raman, phil >> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-07 19:55 ` Stefan Monnier @ 2008-09-08 9:22 ` Richard M. Stallman 0 siblings, 0 replies; 45+ messages in thread From: Richard M. Stallman @ 2008-09-08 9:22 UTC (permalink / raw To: Stefan Monnier Cc: pmr, lennart.borgman, joakim, raman, smeuuh, emacs-devel, phil > 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 8:53 ` Phil Jackson 2008-09-05 9:21 ` joakim @ 2008-09-05 13:33 ` T. V. Raman 1 sibling, 0 replies; 45+ messages in thread From: T. V. Raman @ 2008-09-05 13:33 UTC (permalink / raw To: phil; +Cc: pmr, raman, joakim, emacs-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 4:53 ` Paul Michael Reilly 2008-09-05 6:44 ` joakim @ 2008-09-05 13:32 ` T. V. Raman 1 sibling, 0 replies; 45+ messages in thread From: T. V. Raman @ 2008-09-05 13:32 UTC (permalink / raw To: pmr; +Cc: emacs-devel, 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: An Emacs plug-in for a browser (Firefox?) 2008-09-05 2:42 ` T. V. Raman 2008-09-05 4:53 ` Paul Michael Reilly @ 2008-09-05 20:40 ` Christian Faulhammer 1 sibling, 0 replies; 45+ messages in thread From: Christian Faulhammer @ 2008-09-05 20:40 UTC (permalink / raw To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2008-09-09 8:11 UTC | newest] Thread overview: 45+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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.