Why Emacs should have a good web-browser

[Robert D. Crawford]

"T.V. Raman" <tv.raman.tv@...> writes:

> Note that emacspeak does integrate with firefox via mozrepl ---
> Google for "firebox" --- code is in emacspeak-moz.el.

Thanks.  I'll have to have a look at the code and see what I can figure
out.  What are the disadvantages to doing things like this?  Would it,
with some work, be able to replace w3 or w3m?


>
>
--
Robert D. Crawford                                      rdc1x@...

[Robert D. Crawford]

Adam Wołk <netprobe@...> writes:

>>> Conkeror can be connected both ways with Emacs using mozrepl so I can
>>> imagine (but can't confirm) that one could implement a feature that
>>> would  send website text content directly to emacspeak.
>>
>> If I understand what you are saying, the text would be sent to the
>> speech server but not be rendered in an emacs buffer.  This will not
>> work as it would prevent scrolling through the text, killing/yanking,
>> sending URLs to other processes (mplayer and pdf2text come to mind).
>> I'm not even sure how that would work with emacspeak as it relies on
>> emacs to get its input... at least that is how I understand it.
>>
> I wrongly expressed what I had in mind by 'sending directly to
> emacspeak'.  What I was trying to say is that the text could be pulled
> over from the browser to Emacs which would trigger emacspeak to read
> it. This of course was a mistake on my side as I have no experience
> with emacspeak and wrongly assumed how emacspeak is used and works. I
> stand corrected now but still never meant to imply that Emacs would be
> excluded from the browsing process.

No worries.  I think it was as much my misunderstanding what you were
saying.  

I'm going to have a look at the mozrepl integration with emacspeak as
soon as I get a chance to really look.  Maybe I can report back with
some useful information before the thread dies.

Thanks again,
rdc
--
Robert D. Crawford                                      rdc1x@...

[Chong Yidong]

Stephen Eilert <spedrosa@...> writes:

> Or a way to create vector and bitmap images programatically (some
> Cairo-like elisp library, or bindings for Cairo itself).

Emacs 23 can already do this, because it can be compiled with librsvg.

[paul r-2]

On Tue, 21 Jul 2009 11:52:28 -0400, Stefan Monnier <monnier@...> said:

> It might be possible to use one of those engines as Emacs's rendering
> engine, indeed. To me, it wouldn't seem like an good solution to the
> problem at hand because I don't think it would allow me to control the
> web-browser from Emacs (e.g., how would I access from Elisp the
> content of pages generated from HTML?).

I am not sure I see what type of use case you mean. Like counting
occurences of word « dog » in a page ?

> So it'd be more like embedding Emacs inside a normal browser. It's not
> a bad idea, but I don't think it'll provide as many benefits from
> Emacs's point of view.

I was mainly thinking about the benefits Emacs could get to entrust
buffer rendering to a third party component. In the case of
a xhtml/css+js engine, the advantage is that it is highly standardised,
higly available, and highly maintained, so it would not be a potentialy
dead-end dependance.

--
  Paul

[paul r-2]

On Wed, 22 Jul 2009 01:31:23 +0900, Miles Bader <miles@...> said:

> Most obviously, it's dynamic, and changing it is expected to be very
> cheap even if the buffer is huge.

As some others pointed out, you can easily access to a branch of the DOM
tree without touching the rest, pretty much like with Emacs. If you want
to play with that, install Firefox and its "firebug" extension. Within
minute you will be able to live-change parts of your web pages, both the
content and the style.

> Another issue might be that, to the best of my knowledge, html
> rendering engines tend to generate a "rendered" representation of the
> entire page, no matter how little of it is displayed (as opposed to
> Emacs, which does the most expensive processing mostly only the parts
> of a buffer that are displayed). This has obvious benefits (e.g.,
> scrolling around after the long initial setup can be fast, and your
> scrollbar can easily show physical display units), but has obvious
> problems too: displaying a 1GB file might take a l.o.n.g time to show
> the first page....

Emacs could easily use the big-file-in-many-chunks strategy, the
rendering engine would only be a rendering engine, i.e. no direct access
to file content.

> I don't know how well these engines deal with the underlying text
> changing; given that a small text change might affect the _entire_
> "rendered" data structure, there seems a good chance the answer might
> be "not very well."

Live-editing parts of a big wikipedia article with Firebug is
instantaneous on my good old laptop. The only cascading effect I can
think of is the visual filling, but now emacs does it as well so I'm not
sure it would be worst with a xhtml display engine.

--
  Paul

[Tassilo Horn-5]

Adam Wołk <netprobe@...> writes:

Hi Adam,

> There already exists a browser that tries to implement things the
> Emacs way. It's called conkeror.

I agree that Conkeror is a good browser for emacs users, but I'd like to
add another browser to the discussion: uzbl [1].

It's not specially designed for emacs users (keybindings etc.), but
instead it uses by default vi-like bindings (but those can be modified.)

It uses the slogan that it adheres the UNIX philosophy, e.g. it does one
thing very good (rendering web pages using WebKit) and it delegates
everything else to other tools (downloads, cookies, bookmarks, history,
...), which could be elisp handlers.

IMHO, this approach makes it suited best for creating a browser *inside*
emacs, not just a browser designed *for* emacs users.

Bye,
Tassilo
__________
[1] http://www.uzbl.org/

[Stefan Monnier]

>> It might be possible to use one of those engines as Emacs's rendering
>> engine, indeed. To me, it wouldn't seem like an good solution to the
>> problem at hand because I don't think it would allow me to control the
>> web-browser from Emacs (e.g., how would I access from Elisp the
>> content of pages generated from HTML?).

> I am not sure I see what type of use case you mean. Like counting
> occurences of word « dog » in a page ?

Maybe not the one I was thinking of, but yes, why not.  Or opening a Web
page, and then navigating it with M-C-f, changing its major mode,
killing part of it and yanking it into some other buffer, displaying
various parts of that web page into a bunch of different (Emacs)
windows, ...

> I was mainly thinking about the benefits Emacs could get to entrust
> buffer rendering to a third party component. In the case of
> a xhtml/css+js engine, the advantage is that it is highly standardised,
> higly available, and highly maintained, so it would not be a potentialy
> dead-end dependance.

Yes, of course.  But the rendering from Emacs buffers to those might be
the tricky part (which would require maintenance and work just like
the current rendering engine to X11).  Of course, maybe it'd be easy and
simple enough to be a significant win.  As long as nobody tries, nobody
will know.


        Stefan

[Stephen Eilert]

On Tue, Jul 21, 2009 at 8:05 PM, Chong Yidong<cyd@...> wrote:
> Stephen Eilert <spedrosa@...> writes:
>
>> Or a way to create vector and bitmap images programatically (some
>> Cairo-like elisp library, or bindings for Cairo itself).
>
> Emacs 23 can already do this, because it can be compiled with librsvg.
>

And how do I call it from elisp? I couldn't figure out how.


--Stephen

programmer, n:
        A red eyed, mumbling mammal capable of conversing with
inanimate monsters.

[Chong Yidong]

Stephen Eilert <spedrosa@...> writes:

> On Tue, Jul 21, 2009 at 8:05 PM, Chong Yidong<cyd@...> wrote:
>> Stephen Eilert <spedrosa@...> writes:
>>
>>> Or a way to create vector and bitmap images programatically (some
>>> Cairo-like elisp library, or bindings for Cairo itself).
>>
>> Emacs 23 can already do this, because it can be compiled with librsvg.
>>
>
> And how do I call it from elisp? I couldn't figure out how.

Here's an example:

(setq my-svg-data
      "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?><svg xmlns:svg=\"http://www.w3.org/2000/svg\" xmlns=\"http://www.w3.org/2000/svg\" version=\"1.0\" width=\"223.51666\" height=\"223.76907\" id=\"svg2\"><defs id=\"defs4\" /><g transform=\"translate(-191.24778,-211.49836)\" id=\"layer1\"><path d=\"M 408.57145,369.50505 L 333.90781,368.26904 L 290.56166,429.07444 L 268.66485,357.68315 L 197.44078,335.24841 L 258.57144,292.36219 L 257.8987,217.69136 L 317.57633,262.5775 L 388.38462,238.86313 L 364.13677,309.49051 L 408.57145,369.50505 z\" id=\"path2399\" style=\"opacity:1;fill:#ff0a0a;fill-opacity:0.264574;stroke:#000000;stroke-width:12.38599968;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1\" /></g></svg>")

(setq my-svg-descriptor (create-image my-svg-data 'svg t))
(insert-image my-svg-descriptor)

[Daniel Colascione]

On Jul 8, 2009, at 6:42 PM, Lennart Borgman wrote:
> 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?


Here is an example of some code from espresso (after the rename to js-
mode). I hope the JS interaction  is self-explanatory, at least for  
the purpose of discussion.

(FWIW, maybe the elisp<->js bridge really should be moved to moz.el?)

(defun js--get-tabs ()
   "Enumerate all the contexts available. Each one is a list:

    The list is (TITLE URL BROWSER TAB TABBROWSER) for content documents
    The list is (TITLE URL WINDOW) for windows

    All tabs of a given window are grouped together. The most
    recent window is first. Within each window, the tabs are
    returned left-to-right.
"
   (with-js
    (let (windows)

      (loop with window-mediator = (js! ("Components" "classes"
                                         "@mozilla.org/appshell/window-
mediator;1"
                                         "getService")
                                        (js< "Components" "interfaces"
                                             "nsIWindowMediator"))
            with enumerator = (js! (window-mediator "getEnumerator")  
nil)

            while (js? (js! (enumerator "hasMoreElements")))
            for window = (js! (enumerator "getNext"))
            for window-info = (js-list window
                                       (js< window "document" "title")
                                       (js! (window "location"  
"toString"))
                                       (js< window "closed")
                                       (js< window "windowState"))

            unless (or (js? (fourth window-info))
                       (eq (fifth window-info) 2))
            do (push window-info windows))

      (loop for window-info in windows
            for window = (first window-info)
            collect (list (second window-info)
                          (third window-info)
                          window)

            for gbrowser = (js< window "gBrowser")
            if (js-handle? gbrowser)
            nconc (loop
                   for x below (js< gbrowser "browsers" "length")
                   collect (js-list (js< gbrowser
                                         "browsers"
                                         x
                                         "contentDocument"
                                         "title")

                                    (js! (gbrowser
                                          "browsers"
                                          x
                                          "contentWindow"
                                          "location"
                                          "toString"))
                                    (js< gbrowser
                                         "browsers"
                                         x)

                                    (js! (gbrowser
                                          "tabContainer"
                                          "childNodes"
                                          "item")
                                         x)

                                    gbrowser))))))

[Joakim Verona]

Stefan Monnier <monnier@...> 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).
>
> 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).
>

Would it be posible to consolidate one or the other of the window groups
proposals, and tables? That is, a table cell is somewhat like an Emacs
window.

I played a little bit with having firefox print to pdf, and render pdf
to ascii, and view that in emacs, but it didnt look very good. Better
tables would likely help.


>         Stefan
>
--
Joakim Verona

[martin rudalics]

 > Would it be posible to consolidate one or the other of the window groups
 > proposals, and tables? That is, a table cell is somewhat like an Emacs
 > window.

IIUC tables can have hundreds of cells.  Do you want to create that many
windows?

martin

[Joakim Verona]

martin rudalics <rudalics@...> writes:

>> Would it be posible to consolidate one or the other of the window groups
>> proposals, and tables? That is, a table cell is somewhat like an Emacs
>> window.
>
> IIUC tables can have hundreds of cells.  Do you want to create that many
> windows?

It was just a thought.
Heres some other thoughts:

Use case: text flow around images, which would improve w3m
experience.

a test hack could be to use emacs image-slicing to slice an image in
equal row-height slices, to display text around the image. (maybe the
image slices could be locked in place, dunno)

this is like "rowspan" if an emacs window is a html table. would maybe
be cool with a :rowspan display property.

Some other ideas:
- check out "row overlap" mentioned in dispextern.h
- see if an image could automatically fill a number of "display matrix
cells"


> martin
--
Joakim Verona

[Deniz Dogan-3]

2009/7/8 Fernando <ferkiwi@...>:

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

I'm surprised this hasn't been mentioned in this thread yet:

http://www.haxney.org/2009/08/its-alive.html

--
Deniz Dogan