trouble with CVS and a request for votes

[Charles Hallenbeck]

Hi Kirk -

No question about it, the DOS environment is a piece of cake compared to
the Linux environment. I am not at all unhappy with the way speakup
handles things right now, and I have also learned a few work arounds that
make life easier.

Even in a single process system like DOS, the timing problem is not easy.
The longer you wait to allow the screen to react to the keystroke, the
more sluggish the speech; but the faster you make it, the more errors you
get. Then there is the situation where the user is connected via a modem
program to a remote system, and the timing gets totally out of control.
And those problems are on simple systems.

I mostly wanted to emphasize the distinction between cursor tracking,
which as far as I know speakup has always done flawlessly, and speaking
what the cursor travels over, which is an entirely separate problem.
When I work in pico to edit a text document, I usually do my traveling
with the review cursor instead of the true cursor, and when I find
something I want to fix or change, I use the pico search function to bring
the true cursor to the point of interest. I have no problem living with
the current state of affairs. There are so many other things that speakup
offers that I have no hesitation at all in opting for 1.0.

BTW - Did you know that the very first release of the landmark data base
program "d base" was called "d base II?" There never was a "D Base 1."
Ashton Tate  was convinced that people would have more confidence in a
product with a "II"  after it.

Thanks for all the great work on a fine product.

Chuck


On 29 Sep 2001, Kirk Reiser wrote:

> Hi Chuck and all:  Well let's talk a tad about the difficulty of
> automatic speaking of cursor movement.  In dos and windows the screen
> review program only has external access to the data as in interrupt
> hooks or an os api.  At first glance you would expect that if you have
> total control at the kernel level you would be laughing, right?
> Wrong.  The kernel is absolutely not a sequential device as in you get
> the key, you track the key, the screen handles the key, you say the
> key.  Everything is handled through a series of interrupts which does
> very fast rudimentary handling of the event and then schedules on a
> bottom-half queue.  Okay, so what is a bottom-half queue.  It is a
> routine which runs after the interrupt has happened by a timer.  It
> keeps close attention to how much time is is using and reschedules if
> the jobs are not all handled.  At the same time all of the standard
> processing is also going on as normal.  As you can see we have already
> induced asynchrony in the process.  This also happens with our
> output.  So to cut to the chase, when identify the keystroke we don't
> necessarily have any idea to when the exact time that keys event is/was
> handled by the output routines.  So you track the cursor say what is
> on the screen at that point and woops, the screen hasn't even got
> close to making that change.  You just did the wrong thing at
> absolutely the right time, wrong time, well which was it?  So, maybe
> we want to be smart about it and set our own timer.  Okay, when? How
> do we know whether we're saying the correct event or not?
>
> I do not believe this is an insermountable problem.  I know however it
> will take more examination of the system as a whole and I've already
> spent extensive time on it.  The truth of it is I don't know myself
> the best way to handle it.  So if you don't know, you put it aside and
> work on the myriad other things which need to be done and come back to
> the problem later.  Meantime you hope you gain a better understanding
> on a clear way to handle the problem.
>
> If someone thinks they can jump in and do a better job of it than me,
> please don't hesitate to step up and fix it right.  Until I have a lot
> of other things finished it has moved way down on the priority list.
> It tracks perfectly.  It speaks correctly some of the time, and that's
> all it will do for now.
>
> BTW Chuck, it works worse under emacs than under pico or any other
> editor because emacs has an anoying habbit of bouncing the cursor all
> over the place whenever it crosses a tab-stop position.  When I'm
> editing I almost always have speech output turned off with ins-enter.
> It tracks perfectly then and I don't really care whether it speaks
> every char or line.  I am very familiar with where the review keys are
> and I use them when I want feedback.
>
>   Kirk
>
>

Visit me at http://www.mhonline.net/~chuckh
The Moon is Waxing Gibbous (94% of Full)