Re: question about emacspeak-websearch

[Yvonne Thomson <yvonne@xxxxxxxxxxx>]

At Fri, 26 Sep 2003 13:22:23 +1000,
Tim Cross wrote:
> 
> Hi Yvonne,
> 
> Whenever I need to change the way something in emacspeak works, or for
> that matter any other emacs code, I find emacs' advice facility (see
> defadvice and the emacs lisp manual for details), very useful. Its
> main advantage is that you can modify a functions behavior without
> editing the original code - this avoids having to re-edit everytime
> you do an upgrade. In fact, emacspeak makes extensive use of this
> facility itself. Its also very simple - essentially, you are writing a
> "wrapper" function which can be used to alter inputs before they are
> passed to the original function, alter the return value from the
> function or totally replace the function. 
> 
Thanks, for this, but I knew about advice. The problem is, the code
involved isn't a function. It evaluates, as far as I can tell, after
emacspeak-websearch loads, using eval-after-load, and then changes
browse-url to use w3. I have no idea how to change something like this
with external code. Any help here would be much appreciated.


> One minor correction to a statement in your post. You don't have to
> have w3 installed to do web browsing within emacs/emacspeak. Other
> alternatives are w3m and lynx within a terminal window. 
> 
Er, I know about the alternatives. I'm using w3m, that's why I'm dealing
with this in the first place. But emacspeak support for w3m still
appears to require the emacspeak w3 code, in order to deal with xslt, which makes separating the
browsers at this point a bit awkward.

> It may be possible for Raman to add a customize setting to select the
> preferred web browser. However, this can sometimes be difficult
> because in some instances, there is no 1-to-1 mapping of functions
> between w3 and w3m - that is to say, where in w3 you may be able to
> achieve some particular functionality with just minor coding, doing
> the same within a different browser may require considerably more
> coding. Raman favors w3 over w3m because it offers some features which
> are not available in other browsers like w3m. For example, w3 supports
> auditory cascading style sheets (ACSS) which makes it very easy to
> define a style sheet which will use certain audio attributes for
> various html elements. 
> 
I *know* what the drawbacks are. Trust me on this. I've been using
emacspeak long enough to know this. As a user, I prefer to trade off a
way, *way* faster browser experience for the emacspeak facilities
available with w3. That's my choice to make. Since I've tried to hack
some features that are in emacspeak-w3 that aren't in emacspeak-w3m, I
also know that it's difficult, if not impossible, to achieve some
effects *without* w3. Searching the web with emacspeak-websearch,  however, doesn't seem to be one
of them. I know this, since if I run the emacspeak wizard that already exists, to
change the browser back to w3m, it runs just fine. 

> Finally, Raman is often more receptive to making changes if the
> request includes patches or lisp code which either achieves the
> required modification or goes a long way to doing the job. The main
> reason for this is because he often doesn't have the time to actually
> do the changes himself. so, if you work out some functions to add the
> ability to select the preferred browser for operations like web
> searching and provide them along with your request, the likelyhood of
> them being added to the standard distribution is higher. 
> 
Perhaps, but I don't really know that I'm good enough with elisp to go
there. Not to mention I'm not entirely sure where I would go with this
behaviour. Emacs already specifies a way to specify which browser is
used for web requests, browse-url. I'm not sure that adding another
version that specifys the browser you want to use for emacspeak web requests
vs normal web requests is quite the right way to go. On the other hand,
an option in emacspeak-websearch which specifies whether to use w3 or
some other web browser for searches seems a little specific. As a user,
and not an author, I don't really see why the code I'm talking about is
in there at all, and without knowing the reasoning, I have no idea how
I'd go about patching it to add the customization I'm looking for here.

> I strongly recommend checking out emacs' advice mode. You can find
> lots of examples of its use within emacspeak. I would have to say I
> have found it to be one of the most powerful and simple mechanisms for
> modifying emacs/emacspeak's behavior. Often, when I think there is
> some part of emacs which I would like to behave differently, I will
> first attempt to achieve the different functionality via defadvice,
> use it for a while and possibly refine it. Once it has stabilized and
> appears to be working well, I may then either convert this into a
> stand-alone mode or submit patches to the package author. However,
> most of the time, a simple defadvice is sufficient and I just leave it
> in my personal advice .el file which I load at startup. 
> 
I've used advice myself, mostly for adding speech to my own functions or
giving packages that don't at least a minimum of emacspeak ability. If
I'd been a better elisp programmer, and known what to do in the case of
something not actually being a function, I think I'd've done that, and
not bothered the list with it, which is my usual way of dealing with
these things.

Thanks for your help

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