Did something change with respect to Emacs idle loop:

Did something change with respect to Emacs idle loop:

[T. V. Raman]

I believe the only thing that has changed in my emacs environment
since Monday is Emacs itself (I regularly update from CVS).

That said, I notice the following change in behavior with respect
to subprocesses launched from inside emacs that leads me to
suspect that something has indeed changed, though looking at
Changelog, all timer related changes are in xterm related code,
and I'm seeing this on the console outside of X.

Here is my best attempt at describing the situation; *warning*
it's not going to be something simple that is easily reproducable
-- I'm still trying to find a simple test case.

Symptoms: Run processes like mplayer via start-process from
inside emacs,  e.g. playing an mp3 file ---
output comes to a stop after a fixed length of time -- typically
about a minute. Any form of kbd activity --- even the first key
in a multi-key sequence -- gets things unwedged i.e. the mp3
stream continues to play.

Another situation where I've noticed changed behavior is with
emms (2.1) --- if you launch a playlist  then playback stops
after each track, and you again need to touch the keyboard  for
it to move to the next track.

Again, in both cases, any keypress appears adequate to get things
moving --- even partial keys e.g. C-x where C-x is  a prefix key
making up a key-sequence.

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Did something change with respect to Emacs idle loop:

[T. V. Raman]

Following up to my own message:
I can now confirm that the behavior I describe is due to some
change in Emacs since Sunday.

I did a cvs update -D 2006-09-17 built the result, and the
strange behavior I described with respect to both mplayer and
emms has now gone, things are back as they should be.

Additional details:

This is a desktop system, and it's running powernowd --- though
in the ceasing  up of mp3 streams I describe below, things dont
get unwedged when you have keyboard activity on another console,
so it's not that the entire machine has gone to sleep -- just
Emacs.

So anyway, I believe the bits that changed the behavior got
checked in  since Sep 17, and sometime before Tuesday September
19 -- I started noticing the bizarre behavior first yesterday
evening PDT



>>>>> "tvr" == T V Raman <raman@users.sf.net> writes:
    tvr> I believe the only thing that has changed in my emacs
    tvr> environment since Monday is Emacs itself (I regularly
    tvr> update from CVS).
    tvr> 
    tvr> That said, I notice the following change in behavior
    tvr> with respect to subprocesses launched from inside emacs
    tvr> that leads me to suspect that something has indeed
    tvr> changed, though looking at Changelog, all timer related
    tvr> changes are in xterm related code, and I'm seeing this
    tvr> on the console outside of X.
    tvr> 
    tvr> Here is my best attempt at describing the situation;
    tvr> *warning* it's not going to be something simple that is
    tvr> easily reproducable -- I'm still trying to find a simple
    tvr> test case.
    tvr> 
    tvr> Symptoms: Run processes like mplayer via start-process
    tvr> from inside emacs, e.g. playing an mp3 file --- output
    tvr> comes to a stop after a fixed length of time --
    tvr> typically about a minute. Any form of kbd activity ---
    tvr> even the first key in a multi-key sequence -- gets
    tvr> things unwedged i.e. the mp3 stream continues to play.
    tvr> 
    tvr> Another situation where I've noticed changed behavior is
    tvr> with emms (2.1) --- if you launch a playlist then
    tvr> playback stops after each track, and you again need to
    tvr> touch the keyboard for it to move to the next track.
    tvr> 
    tvr> Again, in both cases, any keypress appears adequate to
    tvr> get things moving --- even partial keys e.g. C-x where
    tvr> C-x is a prefix key making up a key-sequence.
    tvr> 
    tvr> -- Best Regards, --raman
    tvr> 
    tvr>       
    tvr> Email: raman@users.sf.net WWW:
    tvr> http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk:
    tvr> tv.raman.tv@gmail.com PGP:
    tvr> http://emacspeak.sf.net/raman/raman-almaden.asc Google:
    tvr> tv+raman IRC: irc://irc.freenode.net/#emacs
    tvr> 
    tvr> 
    tvr> _______________________________________________
    tvr> Emacs-devel mailing list Emacs-devel@gnu.org
    tvr> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Romain Francoise]

"T. V. Raman" <raman@users.sf.net> writes:

> So anyway, I believe the bits that changed the behavior got checked in
> since Sep 17, and sometime before Tuesday September 19 -- I started
> noticing the bizarre behavior first yesterday evening PDT

Could you try "bisecting" to identify the change which causes this
behavior?

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

That's a bit harder to do -- since Emacs is also my primary
compute environment for getting spoken feedback. I'm happy to do
that as a last resort, but I'd prefer to wait a couple of days
to see if someone can pin-point it to at least a couple of
specific files.

>>>>> "Romain" == Romain Francoise <romain@orebokech.com> writes:
    Romain> "T. V. Raman" <raman@users.sf.net> writes:
    >> So anyway, I believe the bits that changed the behavior
    >> got checked in since Sep 17, and sometime before Tuesday
    >> September 19 -- I started noticing the bizarre behavior
    >> first yesterday evening PDT
    Romain> 
    Romain> Could you try "bisecting" to identify the change
    Romain> which causes this behavior?
    Romain> 
    Romain> -- Romain Francoise <romain@orebokech.com> | The sea!
    Romain> the sea! the open it's a miracle --
    Romain> http://orebokech.com/ | sea! The blue, the fresh, the
    Romain> | ever free! --Bryan W. Procter

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Romain Francoise]

"T. V. Raman" <raman@users.sf.net> writes:

> I'm happy to do that as a last resort, but I'd prefer to wait a couple
> of days to see if someone can pin-point it to at least a couple of
> specific files.

Well, I can't reproduce the bug.  Playing audio files with mplayer (and
Bongo) works fine with current CVS.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Did something change with respect to Emacs idle loop:

[Richard Stallman]

    Symptoms: Run processes like mplayer via start-process from
    inside emacs,  e.g. playing an mp3 file ---
    output comes to a stop after a fixed length of time -- typically
    about a minute. Any form of kbd activity --- even the first key
    in a multi-key sequence -- gets things unwedged i.e. the mp3
    stream continues to play.

Can you run Emacs under GDB and stop it at various times
to see where it is waiting?  Make a backtrace each time.

If you see a pattern in the backtraces, looking one way
while the subprocess is still going, and looking a different way
when it has stopped, that will give us a clue to start from.


Does anyone else observe this problem?

Re: Did something change with respect to Emacs idle loop:

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     Symptoms: Run processes like mplayer via start-process from
>     inside emacs,  e.g. playing an mp3 file ---
>     output comes to a stop after a fixed length of time -- typically
>     about a minute. Any form of kbd activity --- even the first key
>     in a multi-key sequence -- gets things unwedged i.e. the mp3
>     stream continues to play.
>
> Does anyone else observe this problem?

I've tried playing an album through Emacs (today's CVS) like this:

  (apply 'start-process
         (append (list "my-process" nil "/usr/bin/mplayer")
         (cdr (cdr (directory-files "/home/cyd/music/aq" t)))))

15 minutes later, it's still playing; I observe no freeze in the
output.  Do all subprocess all eventually stop for you, or does it
happen only some of the times you run a subprocess?  I've tried this 3
times: on X in an X window, in an xterm with "emacs -nw", and on the
Linux console.

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

Hi, to give more details: I'm not able to reproduce this error on
my laptop --- IBM thinkpad running FC3. On my desktop machine --
amd64 running 32bit Ubuntu the problem appears to be happening
sporadically. 

Couple of additional bits re mplayer:

I use the -slave option so it can be controlled via the keyboard.

mplayer run in this manner from start-process *always* exhibits
the following behavior:
If emacs stomps responding to the keyboard e.g. when some other
process is waiting for the network e.g. nfs disks, mplayer output
stops. Note that this is independent of the new bizarre behavior
 we're tracking down this time around --- I mention it because it
 might be relevant.

My suspicion is that  when this supposed new bug triggers mplayer
locks up in a manner similar to it pausing  when you get the nfs
type problem.

To clarify the nfs-related issue above:

You'll actually see this when mplayer is playing something off of
the local disk while emacs is waiting on an nfs disk  

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:
    Chong> Richard Stallman <rms@gnu.org> writes:
    >> Symptoms: Run processes like mplayer via start-process
    >> from inside emacs, e.g. playing an mp3 file --- output
    >> comes to a stop after a fixed length of time -- typically
    >> about a minute. Any form of kbd activity --- even the
    >> first key in a multi-key sequence -- gets things unwedged
    >> i.e. the mp3 stream continues to play.
    >> 
    >> Does anyone else observe this problem?
    Chong> 
    Chong> I've tried playing an album through Emacs (today's
    Chong> CVS) like this:
    Chong> 
    Chong>   (apply 'start-process (append (list "my-process" nil
    Chong> "/usr/bin/mplayer") (cdr (cdr (directory-files
    Chong> "/home/cyd/music/aq" t)))))
    Chong> 
    Chong> 15 minutes later, it's still playing; I observe no
    Chong> freeze in the output.  Do all subprocess all
    Chong> eventually stop for you, or does it happen only some
    Chong> of the times you run a subprocess?  I've tried this 3
    Chong> times: on X in an X window, in an xterm with "emacs
    Chong> -nw", and on the Linux console.
    Chong> 
    Chong> 
    Chong> _______________________________________________
    Chong> Emacs-devel mailing list Emacs-devel@gnu.org
    Chong> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Richard Stallman]

    You'll actually see this when mplayer is playing something off of
    the local disk while emacs is waiting on an nfs disk  

Are you saying that the problem ONLY happens when Emacs is waiting for
nfs?  I think that's what you're saying, but I'm not 100% sure,
and I'd like to make sure there is no misunderstanding.

If that's the situation, I can guess what the problem might be.

Years ago there were uninterruptible waits in NFS code (I am not sure
which systems this applied to).  That is, a user program (such as
Emacs) would do a system call to use NFS, and that system call would
wait, and it could not be interrupted until the wait finished.  No
signals could be delivered.

If mplayer is trying to output regularly thru a pty to Emacs, Emacs
ought to detect the input and read it every so often.  But Emacs can't
do that if it is in an uninterruptible wait.  So the output buffer
would get full, and then mplayer would hang.

It would be the same if Emacs is computing without waiting for a long
time, since Emacs does not read process output while it is computing.
In that case you could fix the problem by calling
accept-process-output from time to time.  But if NFS causes an
uninterruptible wait, there is nothing Emacs can do about it.

Re: Did something change with respect to Emacs idle loop:

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     You'll actually see this when mplayer is playing something off of
>     the local disk while emacs is waiting on an nfs disk  
>
> Are you saying that the problem ONLY happens when Emacs is waiting for
> nfs?  I think that's what you're saying, but I'm not 100% sure,
> and I'd like to make sure there is no misunderstanding.
>
> If that's the situation, I can guess what the problem might be.
>
> Years ago there were uninterruptible waits in NFS code (I am not sure
> which systems this applied to).  That is, a user program (such as
> Emacs) would do a system call to use NFS, and that system call would
> wait, and it could not be interrupted until the wait finished.  No
> signals could be delivered.
>
> If mplayer is trying to output regularly thru a pty to Emacs, Emacs
> ought to detect the input and read it every so often.  But Emacs can't
> do that if it is in an uninterruptible wait.  So the output buffer
> would get full, and then mplayer would hang.
>
> It would be the same if Emacs is computing without waiting for a long
> time, since Emacs does not read process output while it is computing.
> In that case you could fix the problem by calling
> accept-process-output from time to time.  But if NFS causes an
> uninterruptible wait, there is nothing Emacs can do about it.

I obeserved the same problem some time ago when I was using EMMS(emacs
multimedia system) and mplayer. Mplayer output would stop while Gnus
was doing something network oriented, because Mplayer couldnt print
its output. The solution in my case was to use a player that didnt
rely on being able to print messages to generate audio
output. (Mplayer can still be used with its remote control mode)



-- 
Joakim Verona
http://www.verona.se

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

could you show what emms settings you used to put mplayer in
remote player mode?

>>>>> "joakim" == joakim  <joakim@verona.se> writes:
    joakim> Richard Stallman <rms@gnu.org> writes:
    >> You'll actually see this when mplayer is playing something
    >> off of the local disk while emacs is waiting on an nfs
    >> disk
    >> 
    >> Are you saying that the problem ONLY happens when Emacs is
    >> waiting for nfs?  I think that's what you're saying, but
    >> I'm not 100% sure, and I'd like to make sure there is no
    >> misunderstanding.
    >> 
    >> If that's the situation, I can guess what the problem
    >> might be.
    >> 
    >> Years ago there were uninterruptible waits in NFS code (I
    >> am not sure which systems this applied to).  That is, a
    >> user program (such as Emacs) would do a system call to use
    >> NFS, and that system call would wait, and it could not be
    >> interrupted until the wait finished.  No signals could be
    >> delivered.
    >> 
    >> If mplayer is trying to output regularly thru a pty to
    >> Emacs, Emacs ought to detect the input and read it every
    >> so often.  But Emacs can't do that if it is in an
    >> uninterruptible wait.  So the output buffer would get
    >> full, and then mplayer would hang.
    >> 
    >> It would be the same if Emacs is computing without waiting
    >> for a long time, since Emacs does not read process output
    >> while it is computing.  In that case you could fix the
    >> problem by calling accept-process-output from time to
    >> time.  But if NFS causes an uninterruptible wait, there is
    >> nothing Emacs can do about it.
    joakim> 
    joakim> I obeserved the same problem some time ago when I was
    joakim> using EMMS(emacs multimedia system) and
    joakim> mplayer. Mplayer output would stop while Gnus was
    joakim> doing something network oriented, because Mplayer
    joakim> couldnt print its output. The solution in my case was
    joakim> to use a player that didnt rely on being able to
    joakim> print messages to generate audio output. (Mplayer can
    joakim> still be used with its remote control mode)
    joakim> 
    joakim> 
    joakim> 
    joakim> -- Joakim Verona http://www.verona.se
    joakim> 
    joakim> 
    joakim> 
    joakim> _______________________________________________
    joakim> Emacs-devel mailing list Emacs-devel@gnu.org
    joakim> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Richard Stallman]

    The solution in my case was to use a player that didnt
    rely on being able to print messages to generate audio
    output.

Maybe just redirect that output to /dev/null,
if there is no need for Emacs to look at it.

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

What you say below helps me understand the hangs in the context
of NFS better, but that problem has been there before I reported
this particular problem.

What I was trying to say was:

The hangs I'm seeing when the new alleged bug bites on my ubuntu
box (where there is no nfs  at  present)
is similar to what I've seen mplayer do on systems that do have
nfs.

The hangs are going away on the ubuntu box the moment I touch the keyboard.

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     You'll actually see this when mplayer is playing
    Richard> something off of the local disk while emacs is
    Richard> waiting on an nfs disk
    Richard> 
    Richard> Are you saying that the problem ONLY happens when
    Richard> Emacs is waiting for nfs?  I think that's what
    Richard> you're saying, but I'm not 100% sure, and I'd like
    Richard> to make sure there is no misunderstanding.
    Richard> 
    Richard> If that's the situation, I can guess what the
    Richard> problem might be.
    Richard> 
    Richard> Years ago there were uninterruptible waits in NFS
    Richard> code (I am not sure which systems this applied to).
    Richard> That is, a user program (such as Emacs) would do a
    Richard> system call to use NFS, and that system call would
    Richard> wait, and it could not be interrupted until the wait
    Richard> finished.  No signals could be delivered.
    Richard> 
    Richard> If mplayer is trying to output regularly thru a pty
    Richard> to Emacs, Emacs ought to detect the input and read
    Richard> it every so often.  But Emacs can't do that if it is
    Richard> in an uninterruptible wait.  So the output buffer
    Richard> would get full, and then mplayer would hang.
    Richard> 
    Richard> It would be the same if Emacs is computing without
    Richard> waiting for a long time, since Emacs does not read
    Richard> process output while it is computing.  In that case
    Richard> you could fix the problem by calling
    Richard> accept-process-output from time to time.  But if NFS
    Richard> causes an uninterruptible wait, there is nothing
    Richard> Emacs can do about it.
    Richard> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Richard Stallman]

    The hangs I'm seeing when the new alleged bug bites on my ubuntu
    box (where there is no nfs  at  present)
    is similar to what I've seen mplayer do on systems that do have
    nfs.

    The hangs are going away on the ubuntu box the moment I touch the keyboard.

"When you touch the keyboard" could have various meanings.  Do you
mean "when Emacs receives a keyboard event"?

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

Here, "touch the keyboard" == pressing even a prefix key -- I
think this is equivalent to emacs receiving a kbd event? For
instance, just touch the control  or alt key does not get it
unwedged, pressing ctrl-x (or other prefix keys) gets it unwedged.

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     The hangs I'm seeing when the new alleged bug
    Richard> bites on my ubuntu box (where there is no nfs at
    Richard> present) is similar to what I've seen mplayer do on
    Richard> systems that do have nfs.
    Richard> 
    Richard>     The hangs are going away on the ubuntu box the
    Richard> moment I touch the keyboard.
    Richard> 
    Richard> "When you touch the keyboard" could have various
    Richard> meanings.  Do you mean "when Emacs receives a
    Richard> keyboard event"?

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Richard Stallman]

    Here, "touch the keyboard" == pressing even a prefix key -- I
    think this is equivalent to emacs receiving a kbd event? For
    instance, just touch the control  or alt key does not get it
    unwedged, pressing ctrl-x (or other prefix keys) gets it unwedged.

To get to the bottom of this, I suggest running Emacs under GDB.
When it gets to this situation, you can then investigate what
Emacs is actually doing.

This is assuming that rebuilding with the recompiled Lisp files shows
the problem has not been fixed yet.

Re: Did something change with respect to Emacs idle loop:

[Richard Stallman]

Since other people don't observe the problem,
I think it is up to Raman to debug it.
Other people might be able to help with suggestions,
but only the one who observes the bug can investigate the cause.

Re: Did something change with respect to Emacs idle loop:

[Andreas Seltenreich]

"T. V. Raman" <raman@users.sf.net> writes:

> Another situation where I've noticed changed behavior is with
> emms (2.1) --- if you launch a playlist  then playback stops
> after each track, and you again need to touch the keyboard  for
> it to move to the next track.

Could this be related to the recently-fixed fontification loop
problem?  When investigating with gdb, I noticed that Emacs didn't
leave the following loop in wait_reading_process_output() since
timers_run was repeatedly increased during redisplay, and execution
didn't ever reach the select().

--8<---------------cut here---------------start------------->8---
	  do
	    {
	      int old_timers_run = timers_run;
	      struct buffer *old_buffer = current_buffer;

	      timer_delay = timer_check (1);

	      /* If a timer has run, this might have changed buffers
		 an alike.  Make read_key_sequence aware of that.  */
	      if (timers_run != old_timers_run
		  && old_buffer != current_buffer
		  && waiting_for_user_input_p == -1)
		record_asynch_buffer_change ();

	      if (timers_run != old_timers_run && do_display)
		/* We must retry, since a timer may have requeued itself
		   and that could alter the time_delay.  */
		redisplay_preserve_echo_area (9);
	      else
		break;
	    }
--8<---------------cut here---------------end--------------->8---

HTH
Andreas

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

This does sound like it could be the culprit ---
I'd be happy to test if it were possible to  do a cvs update, and
then undo just this patch and build.

>>>>> "Andreas" == Andreas Seltenreich <seltenreich@gmx.de> writes:
    Andreas> "T. V. Raman" <raman@users.sf.net> writes:
    >> Another situation where I've noticed changed behavior is
    >> with emms (2.1) --- if you launch a playlist then playback
    >> stops after each track, and you again need to touch the
    >> keyboard for it to move to the next track.
    Andreas> 
    Andreas> Could this be related to the recently-fixed
    Andreas> fontification loop problem?  When investigating with
    Andreas> gdb, I noticed that Emacs didn't leave the following
    Andreas> loop in wait_reading_process_output() since
    Andreas> timers_run was repeatedly increased during
    Andreas> redisplay, and execution didn't ever reach the
    Andreas> select().
    Andreas> 
    Andreas> --8<---------------cut
    Andreas> here---------------start------------->8--- do { int
    Andreas> old_timers_run = timers_run; struct buffer
    Andreas> *old_buffer = current_buffer;
    Andreas> 
    Andreas> 	      timer_delay = timer_check (1);
    Andreas> 
    Andreas> 	      /* If a timer has run, this might have
    Andreas> changed buffers an alike.  Make read_key_sequence
    Andreas> aware of that.  */ if (timers_run != old_timers_run
    Andreas> && old_buffer != current_buffer &&
    Andreas> waiting_for_user_input_p == -1)
    Andreas> record_asynch_buffer_change ();
    Andreas> 
    Andreas> 	      if (timers_run != old_timers_run &&
    Andreas> do_display) /* We must retry, since a timer may have
    Andreas> requeued itself and that could alter the time_delay.
    Andreas> */ redisplay_preserve_echo_area (9); else break; }
    Andreas> --8<---------------cut
    Andreas> here---------------end--------------->8---
    Andreas> 
    Andreas> HTH Andreas

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Did something change with respect to Emacs idle loop:

[Andreas Seltenreich]

[fontification loop vs. subprocesses]

"T. V. Raman" <raman@users.sf.net> writes:

> This does sound like it could be the culprit ---
> I'd be happy to test if it were possible to  do a cvs update, and
> then undo just this patch and build.

An easy way to confirm it might be toggling global-font-lock-mode.  If
my guess was right, the symptoms should correlate with that setting.

The last version of jit-lock.el that has the problem is 1.56. So,

    cvs up -r 1.56 lisp/jit-lock.el

should show the symptoms, while

    cvs up -A lisp/jit-lock.el

doesn't.  Note that the file is dumped into Emacs, so besides
byte-compiling it, you'd have to either dump a new emacs or explicitly
load the file for the changes to take effect.

regards,
andreas

Re: Did something change with respect to Emacs idle loop:

[T. V. Raman]

This is to confirm that with Stefan's patch to jit-lock.el, the
problem I was seeing with the idle loop on my desktop machine has
now gone away.


>>>>> "Andreas" == Andreas Seltenreich <seltenreich@gmx.de> writes:
    Andreas> [fontification loop vs. subprocesses] "T. V. Raman"
    Andreas> <raman@users.sf.net> writes:
    Andreas> 
    >> This does sound like it could be the culprit --- I'd be
    >> happy to test if it were possible to do a cvs update, and
    >> then undo just this patch and build.
    Andreas> 
    Andreas> An easy way to confirm it might be toggling
    Andreas> global-font-lock-mode.  If my guess was right, the
    Andreas> symptoms should correlate with that setting.
    Andreas> 
    Andreas> The last version of jit-lock.el that has the problem
    Andreas> is 1.56. So,
    Andreas> 
    Andreas>     cvs up -r 1.56 lisp/jit-lock.el
    Andreas> 
    Andreas> should show the symptoms, while
    Andreas> 
    Andreas>     cvs up -A lisp/jit-lock.el
    Andreas> 
    Andreas> doesn't.  Note that the file is dumped into Emacs,
    Andreas> so besides byte-compiling it, you'd have to either
    Andreas> dump a new emacs or explicitly load the file for the
    Andreas> changes to take effect.
    Andreas> 
    Andreas> regards, andreas

 Thanks, 
 --Raman

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs