emacs-vr-mode-devel

[Emacs-vr-mode-devel] Re: vr-cmd-make-changes

[Patrik J. <pa...@uc...>]

>I see.
>
>I had misunderstood the purpose of the buffer change notification gizmo. I
>thought it was meant to keep Emacs' and DNS' versions of the buffer in sync so
>that you could support "scratch that/correct that". But from what you say, it
>sounds like all vr.el is interested in is is keeping the visible regions in
>sync so that we can support "Select XYZ".
>
>This raises a new question for me. Why do we bother with a complex (and
>probably very fragile) buffer change notification approach instead of sending
>the whole visible region at the beginning of every utterance? Unless you 
>have a
>very slow connection, sending the whole visible region (note: just the visible
>region, not the whole buffer) can't be that expensive.

that's a VERY good question!  This is just the way VR mode is made, and I 
don't know why Barry made that decision.  It might have been that he simply 
wasn't aware of the other possibilities.  I haven't thought about it, my 
changes to VR mode has been evolutionary, not revolutionary... :-)

As for the communication overhead, I don't really know.  I HAVE noticed a 
significant delay when doing the full buffer resynchronization over a 
tunneled secure shell link to external hosts, but I don't remember how 
large those buffers were.  I also have never tried running it over for 
example a DSL link, which I suspect will be significantly slower.

In my mind, the responsiveness of the recognition is one of the most 
important factors affecting how usable it is, so I'd prefer erring on the 
side of caution.  However, this is easily testable!  Simply add (setq 
vr-resynchronize t) at the beginning of get-buffer-info, and a full buffer 
resynchronization will be performed for every utterance.  If you try this 
on a buffer which just about fills your window you should get a pretty good 
estimate of the communications delay.

/Patrik


============================================================
Patrik Jonsson                                  (831) 459-3809
Department of Astronomy & Astrophysics
University of California, Santa Cruz, CA 95064

This message has been written using a voice recognition system.
Words that don't make sense or not the fault of the author...

[Emacs-vr-mode-devel] [Emacs-vr-mode-users] Re: vr-cmd-make-changes

[Patrik J. <pa...@uc...>]

Hey Alain,

At 04:32 PM 2/25/2002 -0500, you wrote:
>Hi Patrik,
>
>How is the situation with your unstable windoze?

I'm recovering.  At least NaturallySpeaking, Emacs and VR mode are working 
again. I had to wipe and reformat my drive, so now I'm slowly reinstalling 
all my software... at least I had no problems backing up all my data before 
I did it.

>I've been cranking away on a version of vr.el that will work with VCode,
>and I'm deeply puzzled by some parts of 'vr-cmd-make-changes.
>In particular this:
>
>     ;; send back a "delete command", since when
>     ;; command is executed it will send the insertion.
>     (let ((cmd (format "change-text \"%s\" %d %d %d %d %s"
>          (buffer-name) (1- (point)) (point)
>          1 (buffer-modified-tick) ""))
>
>It seems that whenever VR.exe tells emacs to make a change to the
>buffer, Emacs reports back a change that is the reverse of the change
>requested by VR.exe.

OK, this is a hack.  It used to be that VR mode would directly insert the 
characters NaturallySpeaking asked it to.  This had some drawbacks, when 
the Emacs key binding was different from just self inserting the same 
character.  For example, in latex mode the double quote is bound to two 
single quotes, and this is the behavior that you would expect when 
dictating as well.

If you study the code, you'll find that this part is only executed when the 
command is not "self-insert-command", which means that the character that 
will be inserted (may be) different from what NaturallySpeaking thinks.  In 
that case, to remain in sync, we must tell NaturallySpeaking that the 
character it thinks is in the buffer has been deleted, and instead the 
character of the key binding is inserted.  This is done by explicitly 
sending the delete command, and then letting the normal change detection 
report what's actually been inserted.

I hope that explains things.


>My best guess at why this is done is that unless Emacs does that, VR.exe
>will end up assuming that everything gets typed in twice. That's
>because:
>
>i) VR.exe is based on VDct which assumes that everything the user says
>is typed verbatim
>
>ii) but Emacs actually does its own thing with the text to be inserted
>(for example, auto-fill) and then reports the changes it actually did to
>VR.exe. To VR.exe, those changes appear exactly as though they were
>typed by the user.
>
>But that doesn't seem to make sense either because the only reason you
>might care about VR.exe's perception of what got typed in response to an
>utterance, is if you wanted to support correction of selected text. But
>there seems to be no way that this scheme can support such correction,
>because Emacs is telling VR.exe that the text it (VR.exe) thought got
>inserted as a result of an utterance is immediatly erased by the user.

your right, you're giving up the "scratch that/correct that" ability in 
order for the buffers to remain synchronized.  The problem is that if you 
don't do this, the buffers will be out of sync, and using select and say 
will produce incorrect results.


>Any idea what the purpose of this hack is?
>
>There is a similar one in

...?  :-)

I assume you meant the "read-only buffer hack".  And its purpose is the 
same, to keep the buffers in sync in order for selection by voice to 
produce the desired results.

by the way, regarding your problem with compiling hook.dll, that code has 
never been changed so you can just copy it from one of the distributed 
versions.  I don't know if you'll still have problems compiling vr.exe, but 
it might help.

I'll go back to your old e-mail and see if there were any questions I 
haven't answered.

/Patrik


============================================================
Patrik Jonsson                                  (831) 459-3809
Department of Astronomy & Astrophysics
University of California, Santa Cruz, CA 95064

This message has been written using a voice recognition system.
Words that don't make sense or not the fault of the author...


_______________________________________________
Emacs-vr-mode-users mailing list
Ema...@li...
https://lists.sourceforge.net/lists/listinfo/emacs-vr-mode-users