Re: Why Emacs should have a good web-browser

[Paul R <paul.r.ml@gmail.com>]

On Wed, 22 Jul 2009 01:31:23 +0900, Miles Bader <miles@gnu.org> 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