Why Emacs should have a good web-browser

[Fernando-49]

Hello.
Sorry if this is not the right place, but I wanted to ask some
questions to the community and expose some arguments.

First, I would like to know if you agree about the reasons for having
a web browser in Emacs (either as part of it or as an external lisp
package).

1) One of the main purposes of Emacs is programming. Web development,
css and JavaScript are emerging languages present a lot in the
internet since a long time and now they are even extending to the
desktop (gnome-shell, seed, adium themes...). Emacs has modes and
tools to edit on this languages, but the integration is not as good as
it could be if you had js and html interpreters integrated in Emacs
itself.

2) There are very few web browsers that are comfortable to use in a
keyboard-only interface. Emacs would be very good in this sense
because its keyboard navigation is very usable and as it's designed
for editing text, it will be perfect for all the form editing, comment
writing and all the editing related actions you have to do often in a
browser (editing wikipedia articles, etc).

3) Emacspeak  has turned Emacs into a very accessible environment for
the visual-impaired and it would offer  these people a highly
customizable interface to help them browse the web, along with the
keybindings.

4) Emacs since long time has been one of the greatest tools for an
operative system. During the Age Of The Usenet it was an good
newsreader. Now that the newsgroups have started to die slowly and the
HTTP protocol and Javascript are the kings of the big cloud Emacs
should adapt to it.

5) Browsers are turning into the next generation Emacs! they can
browse ftp, access IRC channels, check your mail, read pdf and other
things with embeded applications, now they can even play video/audio
as a core functionality, they are often used for editing text (web
forms, comments in blogs, etc)... there's even the whole "Google
Chrome OS" designed around a browser. Sooner or later they will be
able to edit code (there's even prototypes for this already) when this
happens Emacs has to compete or it will slowly die. Web browsers are
turning into the main program for the end/power-user in a PC, when
they reach Emacs in functionality I'm sure a lot of people (even Emacs
users) would end up switching to hack Javascript instead of LISP.

6) The special features of Lisp and the extensibility of Emacs make it
be the perfect candidate for an extensible and modular web browser.
Current browsers are tending to improve their extensibility by means
of "plugins" and "extensions". Emacs has since long time a powerful
scripting that a lot of browsers would envy to have.

- Emacs-w3m is not enough and it's not an Emacs module that can be extended.
- Emacs/w3 was a very good idea but soon it has passed more than 1
year since the last single commit to the git repository, it doesn't
look very active at all (am I wrong?).

So.. I just want to know what's the general feeling of the emacs-dev
community about having an emacs web-browser and what expectations
should we have in this regard, is there any other work being done by
anyone? how much is the interest on this?

Not long ago a new (alpha) version of Guile was released that
introduced some basic support for ECMAscript, announcing that there's
a goal to support up to version 3.1 of the spec. Would this make it
possible for a (distant) future Guile Emacs to be able to have an
efficient Javascript-capable web browser?
There also seems that a bit more of work was put on the Guile elisp
compiler lately, although it's still far from being mature.

--
Fernando
(sorry for my english)

[Chong Yidong]

Fernando <ferkiwi@...> writes:

> First, I would like to know if you agree about the reasons for having
> a web browser in Emacs (either as part of it or as an external lisp
> package).

Rendering the modern web is a very complicated task, and I doubt it's
worthwhile to try to implement this independently in Emacs.

An easier route might be to use Gecko or Webkit to embed webpages in
Emacs windows, in the spirit of how we use the GTK library to draw the
tool-bar and scroll-bar.  Emacs might either link directly to
Gecko/Webkit, or use XEmbed to fit a separate mini-browser process
inside an Emacs window.

AFAIK, no one is currently working on anything like this.

[Richard Riley-4]

Fernando <ferkiwi@...> writes:

> Hello.
> Sorry if this is not the right place, but I wanted to ask some
> questions to the community and expose some arguments.
>
> First, I would like to know if you agree about the reasons for having
> a web browser in Emacs (either as part of it or as an external lisp
> package).
>
> 1) One of the main purposes of Emacs is programming. Web development,
> css and JavaScript are emerging languages present a lot in the
> internet since a long time and now they are even extending to the
> desktop (gnome-shell, seed, adium themes...). Emacs has modes and
> tools to edit on this languages, but the integration is not as good as
> it could be if you had js and html interpreters integrated in Emacs
> itself.
>
> 2) There are very few web browsers that are comfortable to use in a
> keyboard-only interface. Emacs would be very good in this sense
> because its keyboard navigation is very usable and as it's designed
> for editing text, it will be perfect for all the form editing, comment
> writing and all the editing related actions you have to do often in a
> browser (editing wikipedia articles, etc).
>
> 3) Emacspeak  has turned Emacs into a very accessible environment for
> the visual-impaired and it would offer  these people a highly
> customizable interface to help them browse the web, along with the
> keybindings.
>
> 4) Emacs since long time has been one of the greatest tools for an
> operative system. During the Age Of The Usenet it was an good
> newsreader. Now that the newsgroups have started to die slowly and the
> HTTP protocol and Javascript are the kings of the big cloud Emacs
> should adapt to it.
>
> 5) Browsers are turning into the next generation Emacs! they can
> browse ftp, access IRC channels, check your mail, read pdf and other
> things with embeded applications, now they can even play video/audio
> as a core functionality, they are often used for editing text (web
> forms, comments in blogs, etc)... there's even the whole "Google
> Chrome OS" designed around a browser. Sooner or later they will be
> able to edit code (there's even prototypes for this already) when this
> happens Emacs has to compete or it will slowly die. Web browsers are
> turning into the main program for the end/power-user in a PC, when
> they reach Emacs in functionality I'm sure a lot of people (even Emacs
> users) would end up switching to hack Javascript instead of LISP.

You might be interested in looking at controlling/interacting with
Firefox using emacs. Google has more info. I use this below to "refresh"
my firefox when I save local web code. I dont know how well polished it
is. I guess there is a huge load you can do wit whatever that script
language is.


,----
|
| (autoload 'moz-minor-mode "moz" "Mozilla Minor and Inferior Mozilla Modes" t)
|     (add-hook 'espresso-mode-hook 'espresso-custom-setup)
|
| (require 'moz)
|
| (defun espresso-custom-setup ()
|   (moz-minor-mode 1))
|
| (defun auto-reload-firefox-on-after-save-hook ()        
|   (add-hook 'after-save-hook
|    '(lambda ()
|       (interactive)
|       (comint-send-string (inferior-moz-process)
|   "setTimeout(BrowserReload(), \"1000\");"))
|    'append 'local)) ; buffer-local
|
| ;; Example - you may want to add hooks for your own modes.
| ;; I also add this to python-mode when doing django development.
| (add-hook 'nxhtml-mode-hook 'auto-reload-firefox-on-after-save-hook)
| (add-hook 'php-mode-hook 'auto-reload-firefox-on-after-save-hook)
| (add-hook 'html-mode-hook 'auto-reload-firefox-on-after-save-hook)
| (add-hook 'css-mode-hook 'auto-reload-firefox-on-after-save-hook)
`----

[Joakim Verona]

Chong Yidong <cyd@...> writes:

> Fernando <ferkiwi@...> writes:
>
>> First, I would like to know if you agree about the reasons for having
>> a web browser in Emacs (either as part of it or as an external lisp
>> package).
>
> Rendering the modern web is a very complicated task, and I doubt it's
> worthwhile to try to implement this independently in Emacs.
>
> An easier route might be to use Gecko or Webkit to embed webpages in
> Emacs windows, in the spirit of how we use the GTK library to draw the
> tool-bar and scroll-bar.  Emacs might either link directly to
> Gecko/Webkit, or use XEmbed to fit a separate mini-browser process
> inside an Emacs window.
>
> AFAIK, no one is currently working on anything like this.

I would like to point to:
http://www.emacswiki.org/emacs/EmacsXembed

I have some screenshots there of my xembed patch for emacs that allows
xembedding for instance a video player(mplayer in the screenshot) in emacs.

I am currently making a small xembeddable wrapper on webkit that I will
make some screenshots with to show Emacs embedding a browser.

My original aproach was to use Firefox for embedding, since theres a
nice integration with Emacs called MozRepl, but the mozembed component
crashed when trying embedding.

I need to make small wrappers around apps because most apps doesnt
support to be xembedded out of the box. Emacs and Mplayer are easily
xembeddable without modification.

>
--
Joakim Verona

[Lennart Borgman (gmail)]

On Wed, Jul 8, 2009 at 11:55 PM, <joakim@...> wrote:

> Chong Yidong <cyd@...> writes:
>
>> Fernando <ferkiwi@...> writes:
>>
>>> First, I would like to know if you agree about the reasons for having
>>> a web browser in Emacs (either as part of it or as an external lisp
>>> package).
>>
>> Rendering the modern web is a very complicated task, and I doubt it's
>> worthwhile to try to implement this independently in Emacs.
>>
>> An easier route might be to use Gecko or Webkit to embed webpages in
>> Emacs windows, in the spirit of how we use the GTK library to draw the
>> tool-bar and scroll-bar.  Emacs might either link directly to
>> Gecko/Webkit, or use XEmbed to fit a separate mini-browser process
>> inside an Emacs window.
>>
>> AFAIK, no one is currently working on anything like this.
>
> I would like to point to:
> http://www.emacswiki.org/emacs/EmacsXembed
>
> I have some screenshots there of my xembed patch for emacs that allows
> xembedding for instance a video player(mplayer in the screenshot) in emacs.
>
> I am currently making a small xembeddable wrapper on webkit that I will
> make some screenshots with to show Emacs embedding a browser.
>
> My original aproach was to use Firefox for embedding, since theres a
> nice integration with Emacs called MozRepl, but the mozembed component
> crashed when trying embedding.
>
> I need to make small wrappers around apps because most apps doesnt
> support to be xembedded out of the box. Emacs and Mplayer are easily
> xembeddable without modification.

It is probably a very nice piece of job you are doing, but for many
people just controlling Firefox from Emacs would probably be good
enough.

BTW, I have heard that espresso offers even better interaction than
MozRepl but I am not sure. Is there anyone who knows more about this?
Some examples of how to interact from Espresso/MozRepl?

[Chong Yidong]

joakim@... writes:

> I would like to point to:
> http://www.emacswiki.org/emacs/EmacsXembed
>
> I have some screenshots there of my xembed patch for emacs that allows
> xembedding for instance a video player(mplayer in the screenshot) in emacs.
>
> I am currently making a small xembeddable wrapper on webkit that I will
> make some screenshots with to show Emacs embedding a browser.

That's excellent news.

On a technical note, I think it makes more sense to associate embedded
applications with Emacs windows, rather than buffers as you're
apparently trying to do.  Otherwise, we run into the problem of handling
the situation where the same buffer is displayed in more than one
window.  Basically, we should have a way to say "the contents of this
window are handled by an embedded program, rather than by Emacs".  WDYT?

[Lennart Borgman (gmail)]

On Thu, Jul 9, 2009 at 12:55 AM, Chong Yidong<cyd@...> wrote:

> joakim@... writes:
>
>> I would like to point to:
>> http://www.emacswiki.org/emacs/EmacsXembed
>>
>> I have some screenshots there of my xembed patch for emacs that allows
>> xembedding for instance a video player(mplayer in the screenshot) in emacs.
>>
>> I am currently making a small xembeddable wrapper on webkit that I will
>> make some screenshots with to show Emacs embedding a browser.
>
> That's excellent news.
>
> On a technical note, I think it makes more sense to associate embedded
> applications with Emacs windows, rather than buffers as you're
> apparently trying to do.  Otherwise, we run into the problem of handling
> the situation where the same buffer is displayed in more than one
> window.  Basically, we should have a way to say "the contents of this
> window are handled by an embedded program, rather than by Emacs".  WDYT?

You perhaps still need some buffer elements otherwise the embedded
application would go away when you closed a window. That could maybe
be ok, but it is not the way use to behave in Emacs.

Other than that I think it is a good suggestion.

[Davis Herring]

>> On a technical note, I think it makes more sense to associate embedded
>> applications with Emacs windows, rather than buffers as you're
>> apparently trying to do.  Otherwise, we run into the problem of
>> handling
>> the situation where the same buffer is displayed in more than one
>> window.  Basically, we should have a way to say "the contents of this
>> window are handled by an embedded program, rather than by Emacs".
>>  WDYT?
>
> You perhaps still need some buffer elements otherwise the embedded
> application would go away when you closed a window. That could maybe
> be ok, but it is not the way use to behave in Emacs.
>
> Other than that I think it is a good suggestion.

I would say that there should be an "embed object" (sort of like a process
object), and you can do

(set-window-embed window embed)

which fails if EMBED is already associated with some other window.  You
would of course have `window-embed' and `embed-window' which would tell
you that association, so that you could do (set-window-embed (embed-window
embed) nil) to detach it and move it around.

(One could also write it as `set-embed-window', which might make the
single-valuedness of the "embed's window" property clearer.  But I think
it's important to consider it a property of the window because it
overrides everything else that window could ever do.)

Davis

--
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

[Joakim Verona]

Chong Yidong <cyd@...> writes:

> joakim@... writes:
>
>> I would like to point to:
>> http://www.emacswiki.org/emacs/EmacsXembed>
>> I have some screenshots there of my xembed patch for emacs that allows
>> xembedding for instance a video player(mplayer in the screenshot) in emacs.
>>
>> I am currently making a small xembeddable wrapper on webkit that I will
>> make some screenshots with to show Emacs embedding a browser.
>
> That's excellent news.
>
> On a technical note, I think it makes more sense to associate embedded
> applications with Emacs windows, rather than buffers as you're
> apparently trying to do.  Otherwise, we run into the problem of handling
> the situation where the same buffer is displayed in more than one
> window.  Basically, we should have a way to say "the contents of this
> window are handled by an embedded program, rather than by Emacs".  WDYT?

One aproach does not exclude the other.

I modelled my xembed support on the way images are handled in Emacs.

The use-case im really trying to achieve is having any sort of gtk
controller embedded in a buffer. It kind of works already. Embedding an
xembeddable browser, was just a special case of embedding the gtk socket
component.

I want this so I can make guis for controlling multimedia stuff in a
hybrid emacs/traditional gui way.

Personally I dont think embedding a browser in emacs is the way to go
even though it makes for a fun demo. I think the emacs-w3m aproach is
better. I'm also interested in making a similar aproach that would use
mozilla-headless to render the web page in memory, and read the DOM
through something MozRepl like into Emacs buffers.


--
Joakim Verona

[Jason Rumney-4]

Chong Yidong wrote:
> That's excellent news.
>
> On a technical note, I think it makes more sense to associate embedded
> applications with Emacs windows, rather than buffers as you're
> apparently trying to do.  Otherwise, we run into the problem of handling
> the situation where the same buffer is displayed in more than one
> window.  Basically, we should have a way to say "the contents of this
> window are handled by an embedded program, rather than by Emacs".  WDYT?
>  
It's not that difficult to handle, you just need to take snapshots of
the application's display now and then.  The active window contains the
real application, and any other windows can contain a snapshot of the
display of that program.

[Joakim Verona]

Jason Rumney <jasonr@...> writes:

> Chong Yidong wrote:
>> That's excellent news.
>>
>> On a technical note, I think it makes more sense to associate embedded
>> applications with Emacs windows, rather than buffers as you're
>> apparently trying to do.  Otherwise, we run into the problem of handling
>> the situation where the same buffer is displayed in more than one
>> window.  Basically, we should have a way to say "the contents of this
>> window are handled by an embedded program, rather than by Emacs".  WDYT?
>>  
> It's not that difficult to handle, you just need to take snapshots of
> the application's display now and then.  The active window contains
> the real application, and any other windows can contain a snapshot of
> the display of that program.

This is basically what I'm aiming for with my xwidget patch. The active
window contains the live component, the other windows contain inactive
snapshots of the components(currently only grey rectangles in the
inactive windows).

Still, if the list finds the possibility of defering drawing of an
entire emacs window to an xembeddable component, I could try to
implement that on top of my current patch. I would need help on the
design of the interface, that is, where should the properties governing
this go, and what should their names and functions be. I think this
would be useful also, and it could go into the emacs tree way faster
than my current slow-moving xwidget patch.



--
Joakim Verona

[Chong Yidong]

joakim@... writes:

>> It's not that difficult to handle, you just need to take snapshots of
>> the application's display now and then.  The active window contains
>> the real application, and any other windows can contain a snapshot of
>> the display of that program.
>
> This is basically what I'm aiming for with my xwidget patch. The active
> window contains the live component, the other windows contain inactive
> snapshots of the components(currently only grey rectangles in the
> inactive windows).

Is this "snapshot" handled automatically by X (e.g., as an XEmbed
feature), or is it something that would have to be done "by hand",
e.g. by copying one X bitmap buffer into another?  If the latter,
doesn't that mean that clicking on a button in the "copied" application
wouldn't do anything?

[Joakim Verona]

Chong Yidong <cyd@...> writes:

> joakim@... writes:
>
>>> It's not that difficult to handle, you just need to take snapshots of
>>> the application's display now and then.  The active window contains
>>> the real application, and any other windows can contain a snapshot of
>>> the display of that program.
>>
>> This is basically what I'm aiming for with my xwidget patch. The active
>> window contains the live component, the other windows contain inactive
>> snapshots of the components(currently only grey rectangles in the
>> inactive windows).
>
> Is this "snapshot" handled automatically by X (e.g., as an XEmbed
> feature), or is it something that would have to be done "by hand",
> e.g. by copying one X bitmap buffer into another?  If the latter,
> doesn't that mean that clicking on a button in the "copied" application
> wouldn't do anything?

The copying needs to be done manualy yes. However, the xembedded
component is moved to the active window. When clicking on a component in
a non-active window, that window becomes active, so the component is
moved there, and the previously active window gets a copied
component(grey rectangle) instead.


--
Joakim Verona

[paul r-2]

Hi,

Fernando> First, I would like to know if you agree about the reasons for
Fernando> having a web browser in Emacs (either as part of it or as an
Fernando> external lisp package).

As Chong pointed out, rendering today web is a full-time-full-team job.

You might find uzbl[1] of interest. It is basically a frame rendering
the html/css+js, and that's it. Control, bookmarks, history ... well,
everything else than rendering is let to third party tools. IOW, very
suitable for an uzbl-mode.

[1] http://www.uzbl.org/

--
  Paul

[Richard Stallman]

    On a technical note, I think it makes more sense to associate embedded
    applications with Emacs windows, rather than buffers as you're
    apparently trying to do.  Otherwise, we run into the problem of handling
    the situation where the same buffer is displayed in more than one
    window.  Basically, we should have a way to say "the contents of this
    window are handled by an embedded program, rather than by Emacs".

I see what you mean.  In a way, that would be more logical.

But it is hard to fit that into the rest of the way Emacs handles
windows: as spaces within a frame, whose contents are controlled by
the buffer specified for display in the window.  To control a window's
contents in some other way would require a conceptual redesign.

It might be much simpler to avoid that redesign and instead represent
the embedded whatever through a buffer that has a name and can be
displayed in a window.  In addition, this would give a way to ask to
show it, or to replace it with something else: all the usual commands
for switching buffers.

[Stefan Monnier]

> First, I would like to know if you agree about the reasons for having
> a web browser in Emacs (either as part of it or as an external lisp
> package).

I'd like to see Emacs support things like javascript better, as well as
web-browsing.  The Emacs/W3 way is sadly unworkable because of the
amount of effort this requires (compounded by the performance
limitations of Elisp).  Embedding a whole web-browser like Firefox might
be a good direction, tho it's probably too coarse to be satisfactory.
E.g. I'd like to be able to use Emacs's own completion code when typing
the URL or when filling any text in the page.

Maybe the most promising direction I can see is to try and make some
library (like webkit) render directly into an Emacs buffer (rather than
X11/Cairo/w32/plaintext/younameit).  Still, to make it handle tables
properly, we may need to extend Emacs's rendering engine to better
support them (which would be handy in any case for various applications
like list-buffer which should columns of data).


        Stefan

[Robert D. Crawford]

Stefan Monnier <monnier@...> writes:

> Maybe the most promising direction I can see is to try and make some
> library (like webkit) render directly into an Emacs buffer (rather than
> X11/Cairo/w32/plaintext/younameit).  

From a personal standpoint, this is the best idea I've seen in this
thread.  I'm a daily user of emacs/w3 and an more than occasional user
of emacs-w3m.  Being partially sighted and reliant on emacspeak, I
_really_ like the idea of having text rendered into a buffer where it
acts just like any other buffer.

rdc
--
Robert D. Crawford                                      rdc1x@...

[Ken Raeburn-2]

On Jul 11, 2009, at 16:24, Stefan Monnier wrote:
>  The Emacs/W3 way is sadly unworkable because of the
> amount of effort this requires (compounded by the performance
> limitations of Elisp).

Guile has had some performance work done lately, and has a bytecode  
engine of its own; no JIT compilation to machine code yet, but people  
are certainly keeping it in mind.  I don't know how the ECMAScript  
performance compares to a random browser's Javascript engine  
currently, and (according to http://wingolog.org/archives/2009/02/22/ecmascript-for-guile 
  though maybe things have changed) I guess Andy Wingo doesn't  
either.  But the ECMAScript support is a second language reader for  
the compiler, so when the Scheme compilation and optimization support  
improves, so should the ECMAScript support.

Ken

[paul r-2]

Stefan> Maybe the most promising direction I can see is to try and make
Stefan> some library (like webkit) render directly into an Emacs buffer
Stefan> (rather than X11/Cairo/w32/plaintext/younameit). Still, to make
Stefan> it handle tables properly, we may need to extend Emacs's
Stefan> rendering engine to better support them

How about doing that the other way, that is rendering emacs buffers in
webkit (or an other xhtml/css+js lib), making it the default rendering
backend for emacs in graphic mode. It would probably cut off some large
amount of emacs plateform-specific code and make web integration tight.

--
  Paul

[Miles Bader-2]

Paul R <paul.r.ml@...> writes:
> How about doing that the other way, that is rendering emacs buffers in
> webkit (or an other xhtml/css+js lib), making it the default rendering
> backend for emacs in graphic mode. It would probably cut off some large
> amount of emacs plateform-specific code and make web integration tight.

Please give more details about what you mean.  Emacs' display engine is
not simple, and much code relies on its (many) features.  It would seem
quit difficult to make it use a high-level display toolkit with very
different abstractions.

-Miles

--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.