[Emacs-vr-mode-devel] Re: Questions about VR-Mode

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

Hi again,

I'll try to describe the startup sequence for you.  It's different 
depending upon whether VR mode starts VR.exe itself, or whether VR-host is set.

For a remote connection, it's easy.  vr-host and vr-port is set, so Emacs 
is simply opens two network streams to the specified host/port.  The first 
stream is for commands going from Emacs to vr.exe, the second one for the 
other way.  The second stream is attached to vr-output-filter in 
vr.el.  Vr.exe sends "connected" to Emacs, which responds with an 
"initialize"command, telling vr.exe what the window title and class are.

For a local connection, with vr-host nil, things are slightly more 
convoluted since the process has to be started.  Emacs starts the vr.exe 
process, giving it the "-port" option if vr-port is set.  It attaches 
standard output from the process to vr-output-filter.  Vr.exe starts up by 
saying "listening port", which goes *through standard output* to 
vr-output-filter, which executes vr-cmd-listening, which in turn causes 
Emacs to open the network streams to 1 27.0.0.1, on the port given by the 
listening command. once the streams are opened, standard output is detached 
from VR-output-filter.  from there on, things proceed as in the remote case.

This description is mostly based on my understanding of the lisp code, I 
really haven't had much reason to begin to the C++ I/O code, so I could be 
wrong.

Hope that helps,

/Patrik

:11 PM 2/6/2002 -0500, you wrote:
>Patrik Jonsson wrote:
>
> > Hi Alain,
> >
> > Yes, I saw the messages.  I was just too busy to reply until now.
>
>No problem.
>
> > I believe the arm of the differentiates the two streams just based on the
> > fact that one is opened after the other, but I really have never bothered
> > to find out.
>
>Actually, after a closer look at the C++ code, it looks like:
>
>- Emacs opens a first connection on some port X
>- VR.exe acknowledges it with message "listening portNum"
>- Emacs then opens a second connection on the port number it received from 
>VR.exe
>(portNum)
>
>That still seems potentially dangerous. For example, suppose you start two
>instances of emacs at the same time (say by mistake you clicked twice on 
>the Emacs
>icon in your Win2K toolbar). Suppose that instance A sends its first 
>connection
>before instance B, but that for some reason, instance B beats instance A 
>and sends
>its second connection before A does. Then VR.exe will be assume that B's 
>second
>connection actually belongs to A.
>
>It could be that VR.exe acknowledges each initial connection with a 
>different port
>number, in which case there is no problem (becaus A and B each open their 
>follow up
>connection on different ports). But in that case, you can't tunnel through SSH
>because you don't know ahead of time what port numbers VR.exe will assign 
>to the
>various instances.
>
>In VoiceCode what I do is that an editor instance sends a request on a 
>port (called
>the VC_LISTEN port). VoiceCode replies with a randomly generated unique 
>ID. Then
>the editor instance opens a connection on a second port (the VC_TALK 
>port), and
>sends the unique ID it received from VoiceCode. That way, VoiceCode knows 
>for sure
>that this second connection belongs to whatever instance started the first 
>one.
>
> > Having two ports seems to make sense, the only thing is that
> > you have to port-forward two ports instead of one to get through the
> > firewall...
>
>Similar situation to FTP where you have a data and a command ports to forward.
>
> > I'm interested in incorporating whatever improvements you can think of into
> > VR Mode.
>
>That's great! hopefully I won't have to do too much surgery on it to get 
>it to work
>for VoiceCode.
>
>Is it allright if I send you questions? The code for VR-Mode has become 
>much bigger
>than it used to be and I find it difficult to wrap my brain around it.
>
>Here's my first question.
>
>Could you describe to me in a few words the handshaking protocol between 
>Emacs and
>the VR server? From what I saw, it looks something like:
>
>- When a new buffer is started with minor mode vr-mode, Emacs connects to 
>VR.exe on
>the remote machine.
>
>- VR.exe on the remote machine replies with "listening portNum", where 
>portNum is
>the port number it expects the second connection on. Not sure if portNum 
>is the
>same for all instances or if VR.exe assigns a different port on the fly 
>for each
>instance.
>
>- Emacs opens a connection to the LOCAL HOST on portNum. So it seems like 
>there are
>two instances of VR.exe running. One on the local host, one on the remote 
>host. Not
>sure why that is.
>
>
> > Currently, I'm working on a redesign of the communication
>
> > protocol(it's in a branch on the CVS) in order to better handle
> > else-mode.  Basically, the problem occurs when the cursor is sitting in an
> > else placeholder, which Emacs will delete as soon as it receives keyboard
> > input, leading to loss of synchronization and funny spacing in the
> > buffer.  The way I was going to solve it was by sending change commands as
> > soon as an utterance starts, deleting the "volatile" text from the
> > NaturallySpeaking buffer, and then reinserting it when the utterance ends,
> > if it's still there.  Kind of clumsy, but it's the only way I could figure
> > out that solves the two problems above.  The price you pay is by having
> > "scratch that" become invalid, but with a good undo command that shouldn't
> > be too bad.
>
> > I don't know enough about how VoiceCoder is supposed to work to know if the
> > above will be an issue for you as well...
>
>David Fox has designed and is implementing the utterance mapping 
>infrastructure,
>and I don't have a good handle on what he plans to do. My limited 
>understanding of
>it is that it will take into account all the changes that have happened in 
>Emacs as
>a result of an utterance, including things like automatic formatting and 
>automatic
>abbreviation substitutions.
>
> > (By the way, didn't you write an Emacs undo command? (utterance mode?)  I
> > meant to send to a bug report about it hard-crashing my NT Emacs, but I
> > don't remember if actually did.)
>
>No. That might have been Nils Karslund.
>
>Cheers.
>
>Alain

============================================================
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...