[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Read-whole-buffer command and cursor



A few clarifications on why  I never bothered implementing
indexing in emacspeak 
1) Bart's assertion that it was because of lack of two way
communication between emacs and the speech server is not
accurate.
You can have the speech server spit out acknowledgements and
catch these with a process-filter function in emacs 
--in fact I had tried this in earlier versions of emacspeak.

However, the  the timing issue still remains --things get
harder to debug.
gnudoit may well resolve those issues because 
rather than parsing the output of the tcl process in emacs
and blocking for the index, you would have tcl signalling
emacs  with the index, which should prevent some of the
timing woes.


Also,  getting back the last index spoken 
is only half the story --you then need to map this to the
appropriate text chunk in the buffer you're reading.
This is again non-trivial because emacspeak does quite a few
transformations to the text before shipping it off in 
chunks to the speech server. So 
you would at best create some approximation of where you
stopped speech --and spend the rest of the time answering
email explaining why it  was out of sync.
Finally, Matt -- slavishly sticking to what is part of
default emacs is not a productive way to make progress 
if Gary implements a gnudoit based solution --that's well
and good--
gnuserv can always be packaged up.


To return to Gary's message below:
"it should be easy to ..."
Sure --it is doable --doing it might take less time than
talking about it:-)
However,  be aware that though cut 0 might be easy the final
polishing up will take time 
--and it's a judgement call as to how much worth the trouble
it is.
The reason I never wrote it is that I found it not worth the
trouble --this is not to say that it may not be worth 
someone else's while based on time availability and personal
need.

>>>>> "Gary" == Gary Bishop <gb@cs.unc.edu> writes:

    Gary> I thought about doing this with the gnudoit
    Gary> program. This is a member of the gnuclient
    Gary> family. gnuclient is the program that lets a
    Gary> single emacs instance appear to other applications
    Gary> like multiple standalone editors.  gnudoit allows
    Gary> you to tell a running emacs to run a command (some
    Gary> elisp) that you put on gnudoit's command line.

    Gary> Now it seems to me that it would be pretty easy to
    Gary> hack the TCL server so that when speaking is done,
    Gary> it signals emacs through this mechanism. Once you
    Gary> got that going, then you could implement all kinds
    Gary> of synchronization capabilities.

    Gary> gb

    Gary> At 09:12 PM 10/25/99 -0400, Greg E. Priest-Dorman
    Gary> wrote:
    >> >>>>> "W. L." == W L Estes <wlestes@br20920.uncg.edu>
    >> writes:
    >> 
    >> W. L.> ... write a function which speaks a unit of
    >> text...
    >> 
    >> Timing is the problem.  Way back I implimented
    >> something like that but it required doing timing
    >> loops on a given text and even then, somtimes it
    >> would clip the end of one chunk as it began reading
    >> the next - or it would pause just long enough that I
    >> was not sure if it was finished, and then start
    >> reading again.
    >> 
    >> I have found the best solution is to devide the
    >> reading up into some (text dependent) appropriate
    >> sized chunks.  Then read forward by these chunks.
    >> This can be done by using some markup already in the
    >> text or by adding markup to the text.  Either way,
    >> you then are able to use various built in fuctions to
    >> move through the chunks.  For fiction, chapters are
    >> good.  For manuals, I like page or paragraph sized
    >> chunks.  Your mileage may vary.
    >> 
    >> Greg
    >> 
    >> --
    >> Greg Priest-Dorman priestdo@cs.vassar.edu NO
    >> SOLICITING
    >> 
    >> 
    >> -----------------------------------------------------------------------------
    >> To unsubscribe or change your address send mail to
    >> "emacspeak-request@cs.vassar.edu" with a subject of
    >> "unsubscribe" or "help"

    Gary> -----------------------------------------------------------------------------
    Gary> To unsubscribe or change your address send mail to
    Gary> "emacspeak-request@cs.vassar.edu" with a subject
    Gary> of "unsubscribe" or "help"

-- 
Best Regards,
--raman

      
Email:  raman@cs.cornell.edu
WWW:    http://cs.cornell.edu/home/raman/             
PGP:    http://cs.cornell.edu/home/raman/raman.asc 

-----------------------------------------------------------------------------
       To unsubscribe or change your address send mail to
"emacspeak-request@cs.vassar.edu" with a subject of "unsubscribe" or "help"


Emacspeak Files | Subscribe | Unsubscribe