[Emacs-vr-mode-users] Emacs 21 and vrmode: infinite loops in Emacs?

[Nils K. <kla...@re...>]

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
-- 
++

This message was composed using ShortTalk, the spoken editing language
that works.  Occasional strange words, insults, and mumble jumble are
always speech recognition errors.

http://www.research.att.com/~klarlund/ShortTalk