[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Search]
Re: Read-whole-buffer command and cursor
- To: Gary Bishop <gb@xxxxxxxxxxx>
- Subject: Re: Read-whole-buffer command and cursor
- From: "T. V. Raman" <ramantv@xxxxxxxxxxx>
- Date: Tue, 26 Oct 1999 08:04:04 -0700 (PDT)
- In-Reply-To: <4.2.1.10.19991026082332.00a7fc60@xxxxxxxxxxx>
- Old-Return-Path: <raman@xxxxxxxxxxx>
- Resent-Date: Tue, 26 Oct 1999 11:05:34 -0400 (EDT)
- Resent-From: emacspeak@xxxxxxxxxxx
- Resent-Message-ID: <"WwVdZB.A.LnF.kMcF4"@hub>
- Resent-Sender: emacspeak-request@xxxxxxxxxxx
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@xxxxxxxxxxx> 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@xxxxxxxxxxx>
>> 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@xxxxxxxxxxx NO
>> SOLICITING
>>
>>
>> -----------------------------------------------------------------------------
>> To unsubscribe or change your address send mail to
>> "emacspeak-request@xxxxxxxxxxx" with a subject of
>> "unsubscribe" or "help"
Gary> -----------------------------------------------------------------------------
Gary> To unsubscribe or change your address send mail to
Gary> "emacspeak-request@xxxxxxxxxxx" with a subject
Gary> of "unsubscribe" or "help"
--
Best Regards,
--raman
Email: raman@xxxxxxxxxxx
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@xxxxxxxxxxx" with a subject of "unsubscribe" or "help"
Emacspeak Files |
Subscribe |
Unsubscribe