Why Emacs should have a good web-browser

[paul r-2]

Hi Miles,

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

This is a very naïve suggestion, as I dont know much of emacs display
engine. I just notice that emacs wants to display formated text, with
hyperlinks, colors, pictures, antialiasing, etc. All of that (and much
more, like complex layouts, tables, etc) is already very well adressed
in an xhtml/css+js engine such as gecko or webkit, both free software
and available for integration in third party applications.

--
  Paul

[Stefan Monnier]

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

> This is a very naïve suggestion, as I dont know much of emacs display
> engine. I just notice that emacs wants to display formated text, with
> hyperlinks, colors, pictures, antialiasing, etc. All of that (and much
> more, like complex layouts, tables, etc) is already very well adressed
> in an xhtml/css+js engine such as gecko or webkit, both free software
> and available for integration in third party applications.

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


        Stefan

[Miles Bader-2]

Stefan Monnier <monnier@...> writes:

>> This is a very naïve suggestion, as I dont know much of emacs display
>> engine. I just notice that emacs wants to display formated text, with
>> hyperlinks, colors, pictures, antialiasing, etc. All of that (and much
>> more, like complex layouts, tables, etc) is already very well adressed
>> in an xhtml/css+js engine such as gecko or webkit, both free software
>> and available for integration in third party applications.
>
> 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?).  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.

If Emacs used the "high level" rendering component, I dunno how well it
would work, as an Emacs buffer is pretty different than a web page.

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

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

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

But all of this is mostly speculation on my part...

-Miles

--
Bore, n. A person who talks when you wish him to listen.

[davidswelt]

On Jul 21, 2009, at 4:52 PM, Stefan Monnier wrote:
> 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?).

JS / DOM has worked this out quite well, and the implementations  
provide a security model.

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

It would be fantastic to be able to use Emacs directly inside text  
areas of Firefox.  There's a simple plugin that lets users edit text  
from text boxes in an external text editor, but that's nowhere nearly  
as nice as having a little Emacs window displayed right in place of  
the text box.

[Thomas Lord]

On Tue, 2009-07-21 at 11:52 -0400, Stefan Monnier wrote:

> > This is a very naïve suggestion, as I dont know much of emacs display
> > engine. I just notice that emacs wants to display formated text, with
> > hyperlinks, colors, pictures, antialiasing, etc. All of that (and much
> > more, like complex layouts, tables, etc) is already very well adressed
> > in an xhtml/css+js engine such as gecko or webkit, both free software
> > and available for integration in third party applications.
>
> 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?).  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.

It might make an interesting experiment for someone
who has the time and inclination to try writing an
Elisp interpreter and Emacs primitives in Javascript.

-t

[Thomas Lord]

On Wed, 2009-07-22 at 01:31 +0900, Miles Bader wrote:

> 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."
>
> But all of this is mostly speculation on my part...


A modern browser rendering engine presents (e.g.
to Javascript programs) a "DOM" (data object model)
interface to the contents of a page.   The DOM
is a tree structure that functions as a hierarchical
display list and window system windows are automatically
updated from that display list and from changes made
to it.   All of the mechanism of CSS is available to
control the rendering of that display list.

The natural way to use this for an Emacs display
is *not* to try to store all of a buffer's text
in the DOM but rather to use the DOM for only the
visible content of an Emacs frame.   For example,
the scrollbars on a typical browser window would not
be used here:  Emacs would have to implement its own
style of scrollbars as DOM elements.

In terms of performance:  modern browser rendering
kits are fast enough -- although probably only "barely"
so.  They'll get better (through code improvement,
not faster hardware).     People have been building
GUI toolkits that use the DOM as their display engine
for several years now and each year the results
become more and more impressive.

(A question nagging me, lately:  how good would
the performance be of an implementation of Elisp
in Javascript....  The result would be a second
implementation of GNU Emacs, not a replacement for
the GNU Emacs we have.).

-t

[Adam Wołk]

Dnia 21-07-2009 o 19:13:47 Thomas Lord <lord@...> napisał(a):

> On Tue, 2009-07-21 at 11:52 -0400, Stefan Monnier wrote:

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

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

 From their website (http://conkeror.org):
"Conkeror is a keyboard-oriented, highly-customizable, highly-extensible  
web browser based on Mozilla XULRunner, written mainly in JavaScript, and  
inspired by exceptional software such as Emacs and vi. Conkeror features a  
sophisticated keyboard system, allowing users to run commands and interact  
with content in powerful and novel ways. It is self-documenting, featuring  
a powerful interactive help system."

Benefits of helping out with this project:
* Conkeror can be fully controlled from withing emacs using mozrepl
* Doesn't have problems with most pages that Firefox can handle
* Can use existing Firefox extensions (Adblock etc.)
* No problems with websites blocking less popular clients (a very common  
problem even for browsers like Opera)
* Shares many concepts with Emacs

Instead of implementing a full blown browser inside of Emacs, which by  
itself is a massive complicated task both from a usability point of view  
and security. Maybe we should focus on improving the interoperability  
between Emacs and conkeror which already exists and is available.

>
> It might make an interesting experiment for someone
> who has the time and inclination to try writing an
> Elisp interpreter and Emacs primitives in Javascript.
>

As far as I understand, they are not implementing an elisp interpreter but  
javascript is used the same way to provide functionality to the browser.  
Which by itself is quite interesting considering how far they have gone.

[Lennart Borgman (gmail)]

On Tue, Jul 21, 2009 at 8:21 PM, Adam Wołk<netprobe@...> wrote:

> Benefits of helping out with this project:
> * Conkeror can be fully controlled from withing emacs using mozrepl

Please explain in what way it is better to use Conkeror than Firefox for this.

[Adam Wołk]

Dnia 21-07-2009 o 21:01:21 Lennart Borgman <lennart.borgman@...>  
napisał(a):

> On Tue, Jul 21, 2009 at 8:21 PM, Adam Wołk<netprobe@...> wrote:
>
>> Benefits of helping out with this project:
>> * Conkeror can be fully controlled from withing emacs using mozrepl
>
> Please explain in what way it is better to use Conkeror than Firefox for  
> this.

If You refer to mozrepl and scripting only. Then I would assume that  
concepts taken from Emacs and implemented in conkeror will make it a more  
natural platform to extend for current Emacs users. Unfortunately this is  
a wild guess on my part as I really haven't tried to code for either  
platform (conkeror and Firefox).



Some other things that came to my mind:

Conkeror has implemented massive amounts of functionality in ways that  
Emacs users expect.
For example I quickly checked the following set of common tasks with basic  
text edition:
* C-n, C-p, C-f, C-b, M-f, M-b, C-t, M-t, C-a, C-e, C-v, M-v
* C-s, C-r
* C-w,M-w,C-y,C-k
* Marks and regions are used for operations (C-SPACE, C-x C-x)

All of them work as expected. This makes it easier and more natural to tab  
between both applications (Emacs and conkeror).

The interface is styled after Emacs and is designed to be fully keyboard  
driven.
The browser works with 'buffers' while firefox still defaults to tabs.
It's actively developed and mostly by people who already are Emacs users.
Do to the nature of the project it should be easier to have specific  
features accepted in the upstream then with Firefox.
Consider sending a patch for Firefox to improve Emacs compatibility - I  
don't think it would concern most developers.

Of course this could be done as an extensions to Firefox. In fact conkeror  
started that way and they decided to go all the way down.

I believe that having a good default and supported browser that integrates  
well with Emacs would be great.

[Lennart Borgman (gmail)]

2009/7/21 Adam Wołk <netprobe@...>:

> Dnia 21-07-2009 o 21:01:21 Lennart Borgman <lennart.borgman@...>
> napisał(a):
>
>> On Tue, Jul 21, 2009 at 8:21 PM, Adam Wołk<netprobe@...> wrote:
>>
>>> Benefits of helping out with this project:
>>> * Conkeror can be fully controlled from withing emacs using mozrepl
>>
>> Please explain in what way it is better to use Conkeror than Firefox for
>> this.
>
> If You refer to mozrepl and scripting only. Then I would assume that
> concepts taken from Emacs and implemented in conkeror will make it a more
> natural platform to extend for current Emacs users. Unfortunately this is a
> wild guess on my part as I really haven't tried to code for either platform
> (conkeror and Firefox).

Thanks for explaining.

> Some other things that came to my mind:
>
> Conkeror has implemented massive amounts of functionality in ways that Emacs
> users expect.
> For example I quickly checked the following set of common tasks with basic
> text edition:
> * C-n, C-p, C-f, C-b, M-f, M-b, C-t, M-t, C-a, C-e, C-v, M-v
> * C-s, C-r
> * C-w,M-w,C-y,C-k
> * Marks and regions are used for operations (C-SPACE, C-x C-x)
>
> All of them work as expected. This makes it easier and more natural to tab
> between both applications (Emacs and conkeror).

There are some users of Emacs (like me) that never use these key
bindings since we prefer Viper. So we would really want a combination
of vi+emacs keybindings in other applications too.

[Adam Wołk]

Dnia 21-07-2009 o 21:33:33 Lennart Borgman <lennart.borgman@...>  
napisał(a):


> There are some users of Emacs (like me) that never use these key
> bindings since we prefer Viper. So we would really want a combination
> of vi+emacs keybindings in other applications too.

I saw this question recently on the conkeror mailing list.
It seems that there are no ready to use bindings or modes for people who  
prefer vim key bindings but I believe that this could be implemented (at  
least partially?).

Below are some quotes from the conkeror mailing list archives:

quote from http://article.gmane.org/gmane.comp.mozilla.conkeror/1580 :

> Some vi-like search bindings:
>
>   define_key(content_buffer_normal_keymap, "/", "isearch-forward");
>   define_key(content_buffer_normal_keymap, "?", "isearch-backward");
>   define_key(content_buffer_normal_keymap, "n",  
> "isearch-continue-forward");
>   define_key(content_buffer_normal_keymap, "N",  
> "isearch-continue-backward");
>
> The commands isearch-continue-[forward/backward] are bound on S and R
> by default, and you may just want to use those unless you are planning
> to make a whole new binding set.
>
>> open link in new buffer with F instead of C-u f
>
>   define_key(content_buffer_normal_keymap, "F", "follow-new-buffer");

quote from http://article.gmane.org/gmane.comp.mozilla.conkeror/1587 :

>> Thanks for the tips. I understand that conkeror could be made to behave  
>> like
>> vimperator by changing keybindings. What I actually wanted to know is  
>> if it
>> is possible to make conkeror "completely" behave like Vimperator "only"  
>> by
>> changing the keybindings or does one need to do more than that (for  
>> example,
>> some deeper hacking)?
>
> Changing key bindings will likely get you much of the way to vimperator,
> but it will indeed not get you an exact clone of vimperator.  For one
> thing, not all UI decisions are represented as key binding choices, and
> for another, there are some features in vimperator not supported in
> Conkeror (though also some things in Conkeror not supported in
> Vimperator).
>
> I would think that changing the key bindings would be mostly sufficient,
> though.

[Robert D. Crawford]

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

> I believe that having a good default and supported browser that
> integrates well with Emacs would be great.

Correct me if I am wrong, but this does not sound like "default" but
more like "de facto," the difference being that we are talking about
separate applications that run independently of each other.  

I will not pretend to understand everything that is being discussed.  I
am interested as a blind user, dependent on w3 and or emacs-w3m.  So
far, I don't see how I will be able to use emacspeak to speak the
contents of a conqueror buffer like I can any other emacs buffer.  Am I
mistaken?  

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

[Lennart Borgman (gmail)]

On Tue, Jul 21, 2009 at 10:02 PM, Robert D. Crawford<rdc1x@...> wrote:

> I will not pretend to understand everything that is being discussed.  I
> am interested as a blind user, dependent on w3 and or emacs-w3m.  So
> far, I don't see how I will be able to use emacspeak to speak the
> contents of a conqueror buffer like I can any other emacs buffer.  Am I
> mistaken?

Hi Robert,

Is emacspeak in any way dependent on w3 or could it do equally well if
emacs-w3m could use another web browser to do what it does now?

[Adam Wołk]

Dnia 21-07-2009 o 22:02:28 Robert D. Crawford <rdc1x@...>  
napisał(a):

> Adam Wołk <netprobe@...> writes:
>
>> I believe that having a good default and supported browser that
>> integrates well with Emacs would be great.
>
> Correct me if I am wrong, but this does not sound like "default" but
> more like "de facto," the difference being that we are talking about
> separate applications that run independently of each other.
>

They run independently as applications but thanks to extensions like  
mozrepl they can communicate the same way as Emacs + SLIME can with many  
Common Lisp implementations. So really embracing mozrepl would allow  
building a bridge between regular Emacs usage and browsing, focusing on  
conkeror allows us to have a more familiar environment both for usage and  
extending.

> I will not pretend to understand everything that is being discussed.  I
> am interested as a blind user, dependent on w3 and or emacs-w3m.  So
> far, I don't see how I will be able to use emacspeak to speak the
> contents of a conqueror buffer like I can any other emacs buffer.  Am I
> mistaken?
>
> rdc

quote from mozrepl website:
> Connect to Firefox and other Mozilla apps, explore and modify them from  
> the inside, while they're running.
> Execute Javascript, play with browser GUI, sneak into HTML pages,  
> examine functions and variables, redefine them on the fly, hot-fix
> bugs, ... MozRepl itself is programmable from within MozRepl.

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.

So my guess is that You could not only pass every browser buffer to  
emacspeak but also wouldn't have problems with pages using heavy  
javascript and flash for navigation. Before You take my words for granted  
it would be wise to wait for confirmation of this possibility from someone  
with actual experience with mozrepl.

I also saw a browser extension for Firefox called 'It's all text' that  
could send text input elements from forms and allow to edit them in  
external editors, sending it back when the editor saved the file. If  
exporting text from regular Firefox this way is possible then I assume  
that the website text content wouldn't be much different.

[Chong Yidong]

David Reitter <david.reitter@...> writes:

> It would be fantastic to be able to use Emacs directly inside text
> areas of Firefox.  There's a simple plugin that lets users edit text
> from text boxes in an external text editor, but that's nowhere nearly
> as nice as having a little Emacs window displayed right in place of
> the text box.

This should be doable on X, with the existing XEmbed support.

[Robert D. Crawford]

Lennart Borgman <lennart.borgman@...> writes:

> Is emacspeak in any way dependent on w3 or could it do equally well if
> emacs-w3m could use another web browser to do what it does now?

emacspeak is not dependent on any particular browser, it is just
dependent on emacs.  I can use w3 or w3m... both work equally well as
far as getting the content rendered to a buffer so that it can be
spoken.  The differences are mainly in what can be done in each browser
e.g. in w3 you can navigate tables cell-by-cell and there are some
limitations imposed by the underlying w3m that mean it cannot render
certain tags in different faces.

So, yes, if emacs-w3m used a different backend it should work equally
well.  I think the main point is that the web page gets rendered as
_text_, marked up in different faces to denote various tags and
presented just as any other buffer.  One of the nice things about this
sort of set-up is that transformations can be made to the text before it
is rendered.  A good example is transforming table based layouts so that
each cell becomes a paragraph, making it possible to read in a linear
fashion.

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

[Robert D. Crawford]

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

> Dnia 21-07-2009 o 22:02:28 Robert D. Crawford <rdc1x@...>
> napisał(a):
>
>> Adam Wołk <netprobe@...> writes:
>>
>>> I believe that having a good default and supported browser that
>>> integrates well with Emacs would be great.
>>
>> Correct me if I am wrong, but this does not sound like "default" but
>> more like "de facto," the difference being that we are talking about
>> separate applications that run independently of each other.
>
> They run independently as applications but thanks to extensions like
> mozrepl they can communicate the same way as Emacs + SLIME can with
> many  Common Lisp implementations. So really embracing mozrepl would
> allow  building a bridge between regular Emacs usage and browsing,
> focusing on  conkeror allows us to have a more familiar environment
> both for usage and  extending.

Granted.  I like the interaction of a REPL.  I've played with the python
REPL in emacs and I see it as working like emacs-w3m in that the user
sends commands and the output gets sent to an emacs buffer.  This works
well as it just becomes more text that can be "read" through like any
other buffer.  

> quote from mozrepl website:
>> Connect to Firefox and other Mozilla apps, explore and modify them
>> from the inside, while they're running.
>> Execute Javascript, play with browser GUI, sneak into HTML pages,
>> examine functions and variables, redefine them on the fly, hot-fix
>> bugs, ... MozRepl itself is programmable from within MozRepl.
>
> 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.

> So my guess is that You could not only pass every browser buffer to
> emacspeak but also wouldn't have problems with pages using heavy
> javascript and flash for navigation. Before You take my words for
> granted  it would be wise to wait for confirmation of this possibility
> from someone  with actual experience with mozrepl.

There is some integration between emacspeak and the mozrepl.  I've not
played with it in a very long time so I don't know exactly what it can
do.  I do know that Dr. Raman was using it for javascript development
but not for browsing.

> I also saw a browser extension for Firefox called 'It's all text' that
> could send text input elements from forms and allow to edit them in
> external editors, sending it back when the editor saved the file. If
> exporting text from regular Firefox this way is possible then I assume
> that the website text content wouldn't be much different.

I guess what I'm really hoping for is the speed of emacs-w3m with the
extensibility of emacs/w3.  The main purpose of my posting is to try to
move things in the direction of adding more accessibility to emacs.
Plus, having a browser that can replace w3, which is getting really old,
is a good idea.

Thanks for listening,
rdc
--
Robert D. Crawford                                      rdc1x@...

[T.V. Raman]

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

That code needs some updating to make keyboard input work with
Firefox 3 --- things changed on the firefox side post FF2, and
I've not had the chance to finish the work.

But roughly, here is how it works:

0. I start Firefox with mozrepl enabled --- in my case I tell FF
to use an Xvfb created framebuffer --- but that's just an aside,
since I dont start Gnome or any other graphical desktop --- my
desktop is Emacs.

1. From emacs, I open a repl interaction handle via which I can
send forms to FF  for evaluation.

2. On the FF side, I load in a JS  library I wrote called adom.js
http://emacspeak.googlecode.com/svn/trunk/js/

that defines a set of helper functions in JS  -- facilitate
receiving HTML in emacs back from Firefox.


--
Best Regards,
--raman

Title:  Research Scientist
Email:  raman@...
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  raman@..., tv.raman.tv@...
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc


3. Finally, I define a special Mozilla interaction mode where I
can send js commands to FF  from Emacs, and the response back as
HTML  --- I then hand off this HTML  to either W3 or W3M  for
processing.

All this works upto a point --- except that at present keyboard
input to FF from the emacs side is broken.

In effect, the above turns FF  into a DOM-server for Emacs.

--
Best Regards,
--raman

Title:  Research Scientist
Email:  raman@...
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  raman@..., tv.raman.tv@...
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc



On 7/21/09, Robert D. Crawford <rdc1x@...> wrote:

> Adam Wołk <netprobe@...> writes:
>
>> Dnia 21-07-2009 o 22:02:28 Robert D. Crawford <rdc1x@...>
>> napisał(a):
>>
>>> Adam Wołk <netprobe@...> writes:
>>>
>>>> I believe that having a good default and supported browser that
>>>> integrates well with Emacs would be great.
>>>
>>> Correct me if I am wrong, but this does not sound like "default" but
>>> more like "de facto," the difference being that we are talking about
>>> separate applications that run independently of each other.
>>
>> They run independently as applications but thanks to extensions like
>> mozrepl they can communicate the same way as Emacs + SLIME can with
>> many  Common Lisp implementations. So really embracing mozrepl would
>> allow  building a bridge between regular Emacs usage and browsing,
>> focusing on  conkeror allows us to have a more familiar environment
>> both for usage and  extending.
>
> Granted.  I like the interaction of a REPL.  I've played with the python
> REPL in emacs and I see it as working like emacs-w3m in that the user
> sends commands and the output gets sent to an emacs buffer.  This works
> well as it just becomes more text that can be "read" through like any
> other buffer.
>
>> quote from mozrepl website:
>>> Connect to Firefox and other Mozilla apps, explore and modify them
>>> from the inside, while they're running.
>>> Execute Javascript, play with browser GUI, sneak into HTML pages,
>>> examine functions and variables, redefine them on the fly, hot-fix
>>> bugs, ... MozRepl itself is programmable from within MozRepl.
>>
>> 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.
>
>> So my guess is that You could not only pass every browser buffer to
>> emacspeak but also wouldn't have problems with pages using heavy
>> javascript and flash for navigation. Before You take my words for
>> granted  it would be wise to wait for confirmation of this possibility
>> from someone  with actual experience with mozrepl.
>
> There is some integration between emacspeak and the mozrepl.  I've not
> played with it in a very long time so I don't know exactly what it can
> do.  I do know that Dr. Raman was using it for javascript development
> but not for browsing.
>
>> I also saw a browser extension for Firefox called 'It's all text' that
>> could send text input elements from forms and allow to edit them in
>> external editors, sending it back when the editor saved the file. If
>> exporting text from regular Firefox this way is possible then I assume
>> that the website text content wouldn't be much different.
>
> I guess what I'm really hoping for is the speed of emacs-w3m with the
> extensibility of emacs/w3.  The main purpose of my posting is to try to
> move things in the direction of adding more accessibility to emacs.
> Plus, having a browser that can replace w3, which is getting really old,
> is a good idea.
>
> Thanks for listening,
> rdc
> --
> Robert D. Crawford                                      rdc1x@...
>
>
>
>

[Adam Wołk]

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

[Stephen Eilert]

[ Forgot to reply to the list. My bad ]



On Fri, Jul 17, 2009 at 10:29 PM, Miles Bader<miles@...> wrote:

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

I don't think there's any problem that Emacs doesn't look like a
"native" application. The problem is that it looks like an "old"
application.
If you take screenshots from Emacs and Textmate, both with their
"factory" defaults, Textmate looks *much* nicer (even though its
window consists mostly of text too). However, my heavily customized
Emacs looks prettier (IMHO) than the default, as does this one:
http://ozmm.org/posts/textmate_minor_mode.html

So, I think there are two issues here: first, better defaults. This
not only includes CUA-mode (even though I don't use it), but also XFT,
and the best font rendering we can get. Emacs 23 is close.

But it also needs more in the way of graphics. Even though Emacs
buffers *can* display graphics, their use is fairly limited(I see some
icons in Gnus, avatar faces in twit.el, line breaks, and the
speedbar). But these icons are small, not able to be changed in an
obvious way, are bitmaps, and are ugly.

So, we either need a better way to package graphics, as the preferred
distribution method seems to be EmacsWiki .el script files, so a
proper package manager. Or a way to create vector and bitmap images
programatically (some Cairo-like elisp library, or bindings for Cairo
itself).

I am a developer, though I've only hacked my personal .emacs so far,
but those are both interesting projects (package manager or graphics
library).


--Stephen

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