Hi,
My apologies for taking forever to respond, progress on my thesis had to
take priority for awhile, and I also can't contribute much to the problem...
There seems to be several outstanding issues with Emacs 21, I can't run it
for more than a short while until there is some breakdown in buffer
synchronization. I haven't had time to look into it much, but I don't see
anything obvious that would cause it. Instead, I've simply reverted to
Emacs 20. This is not ideal, but I hesitate to put in a large effort in VR
mode when it probably will be superseded by VoiceCoder anyway... (There is
also the FREQUENT problem of buffer confusion and communication timeout
giving the assertion failure that I don't know how to solve.)
incidentally, I also get Emacs lockups which you can NOT get out of using
Ctrl-g or any other way I know of. Emacs is stuck in a busy loop sucking
CPU, and the only way I've found of getting out of it is by killing the
Emacs process. However, I suspect this is a problem with tramp (which I'm
also using) and not VR mode.
On the other hand, if anyone is interested in pursuing the existing
problems with VR mode, I will offer all help I can...
/Patrik
At 09:36 PM 1/2/2003 -0500, Nils Klarlund wrote:
>Hello Patrick (and others!):
>
>I am trying to make Emacs 21 work with vr-mode. I am running under
>Windows 2000. I have experimented with Emacs version 21.2, 21.2.92,
>and 21.2.93 and vrmode version 008. There is a very, very tricky
>problem, which I believe is not connected to the specialized use of
>the software that I've undertaken (which consists of using only the
>fundamentals of vrmode, no commands, no bookkeeping of separate
>buffers, etc.). Still, there is an intermittent problem, which is due
>to Emacs 21 I suspect.
>
>Once in a while, it happens that events stuffed into
>unread-command-events during the execution of vr-cmd-make-changes are
>not executed as expected. Instead, Emacs seems to go into an infinite
>loop, actively polling some flag or condition. If I do a C-g, then I
>get *no* information about what was aborted, but the action itself is
>enough to pull Emacs out of the infinite loop. Also, the events in
>unread-command-events are then properly executed. The infinite loop
>can be abandoned also by hitting any other key, such as SPC. Then,
>the events in unread-command-events are properly executed followed by
>SPC.
>
>I have tried to follow the vrmode protocol live using the debugging
>window. It seems as if all communications are normal. That led me
>to believe that there is a bug in Emacs.
>
>At one point, I made more frequent use of vr-resynchronize, which
>seems to make the problem significantly worse. (In general, my use of
>vrmode makes it unnecessary to send information about the whole buffer
>contents back to vrmode.) Also, I have a suspicion that after
>computationally expensive tasks, the problem is more like to occur.
>Currently, it happens maybe for every fifty or so utterances.
>Certainly frequently enough to be bothersome.
>
>I noticed another bug in Emacs 21: the message function is echoed in a
>very strange way when called from within one of the functions that
>triggered by process filters. The first character and only the first
>character is registered by the *Messages* buffer. The whole message
>is echoed in the minibuffer area, however. So, that reinforces my
>suspicion that Emacs 21 is not yet implementing process communication
>in a quite stable way.
>
>At this point, the situation is sufficiently fuzzy that I have not
>written to the GNU people. Have anybody else experienced something
>similar? If this is a general issue it would be nice to have it
>fixed, since Emacs 21 seems to catch up on many fronts.
>
>/Nils
--
============================================================
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...
|
