Re: Why Emacs should have a good web-browser

["Robert D. Crawford" <rdc1x@comcast.net>]

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

> Dnia 21-07-2009 o 22:02:28 Robert D. Crawford <rdc1x@comcast.net>
> napisał(a):
>
>> Adam Wołk <netprobe@gmail.com> 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@comcast.net