Future directions for browsers in emacspeak

["T. V. Raman" <raman@xxxxxxxxxxx>]

everthing you say is correct. 

My own thinking on this was to try to get one of the
emacs/firefox integration bits working -- people claim to have
Firefox plugins that let them write javaScript in an emacs buffer
and then send it to Firefox for evaluation -- it's a plugin to
aid debugging. The advantage from an emacspeak perspective is
that those plugins then allow ou to walk the DOM of the document
you're looking at, so we could essentially get exactly what
you're  suggesting; namely, let Firefox do the heavy lifting of
handling badly formed HTML and giving us a reasonable DOM to work
with, and Emacspeak/emacs doing the speech interaction.

To date I've not succeeded in getting any of those plugins to
work; just do a Google search for Emacs firefox javascript and
you'll find the ones I found.

I'll also admit to not having  spent too much time trying to get
them to work.

So if you have the time and the energy, that's where i'd suggest
starting; once we have one of those beasts running predictably
the rest should be fun to build.

>>>>> "Lukas" == Lukas Loehrer <listaddr1@xxxxxxxxxxx> writes:
    Lukas> Sorry for hijacking the thread, but this has been
    Lukas> bugging me for some time. I wonder if neither w3m nor
    Lukas> w3 are the way to go for the future. Both of these
    Lukas> browser try to render the web page visually which is
    Lukas> really a waste of effort for people who cannot read
    Lukas> the screen. It occured to me that a web browser for
    Lukas> blind people is really just a fancy way to navigate
    Lukas> the DOM of the page at hand, so one is more interested
    Lukas> in the logical structure of the document than in one
    Lukas> possible visual representation provided by thos
    Lukas> browsers.
    Lukas> 
    Lukas> I like the w3m way of having an external process do
    Lukas> most of the work, so emacs is not blocked. I first
    Lukas> thought one could write a program using libtidy to get
    Lukas> the dom of web pages. While this solution would be
    Lukas> rather easy to implement using existing bindings to
    Lukas> libtidy for example from python, it would not give us
    Lukas> support for advanced features like javascript that as
    Lukas> Tim mentions are becoming more and more important.
    Lukas> 
    Lukas> So, it seems that a real browser engine like khtml or
    Lukas> gecko has to be employed. I mean not the part that
    Lukas> does the rendering but only thos parts that fetch the
    Lukas> page and manage the DOM. Good bindings for a friendly
    Lukas> language like python, perl or ruby would be very
    Lukas> helpful in such an project.
    Lukas> 
    Lukas> The external program could then offer a simple
    Lukas> interface that could be wrapped from emacspeak, in
    Lukas> order to navigate the page.
    Lukas> 
    Lukas> The above is just a kind of brain dump, not an outline
    Lukas> for a real project. I am not suggesting that anyone
    Lukas> (except maybe myself) gets to work on this
    Lukas> tomorrow. Still, I would be very interested in input
    Lukas> on the general direction proposed above.
    Lukas> 
    Lukas> Best regards, Lukas
    Lukas> 
    Lukas> Tim Cross writes ("w3m and reading www pages with
    Lukas> multiple collumns"):
    >> Hi Paul,
    >> 
    >> I actually find both w3 and w3m are useful. For some
    >> pages, w3 does a nice job and you get a very nice
    >> intergration with emacspeak. In other situations, w3m is
    >> better. Depending on your distribution, it can be a little
    >> time consuming to install w3. Debian has it as a package
    >> and it is reasonably up to date. However, you really need
    >> the latest w3 CVS version to get the best result.
    >> 
    >> While it is not an ideal situation, at least with both
    >> browsers, we get a reasonable coverage. I think part of
    >> the problem is that development of w3 stalled a few years
    >> back and now with w3m, there is even less motivation for
    >> others to contribute to w3. From an emacs perspective, I
    >> think there is more potential for better integration with
    >> w3, but w3m has some advantages with respect to speed and
    >> the rendering of pages.
    >> 
    >> It will be interesting to see what happens in the future
    >> considering the growth in use of Ajax. Some experimental
    >> work has been done in implementing javascript support for
    >> w3, but I don't know about w3m.
    >> 
    >> Tim
    Lukas> 
    Lukas> -----------------------------------------------------------------------------
    Lukas> To unsubscribe from the emacspeak list or change your
    Lukas> address on the emacspeak list send mail to
    Lukas> "emacspeak-request@xxxxxxxxxxx" with a subject of
    Lukas> "unsubscribe" or "help"

-- 
Best Regards,
--raman

      
Email:  raman@xxxxxxxxxxx
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@xxxxxxxxxxx
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help"