bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  20285@debbugs.gnu.org
> Date: Sat, 11 Apr 2015 21:24:18 +0200
> 
> > I can only understand a much more frequent redisplay if you have a lot
> > of timers, or a high-frequency timer.  When a timer fires, we call
> > redisplay, AFAIR.
> 
> I have a lot of timers but they aren't too high frequency.

They could be if taken together.

> But I think Stefan's explanation (which is the same as you write
> below) is correct, i.e., a redisplay is triggered by new output
> received from the async latex compile process.

It is triggered if there's a small time window between two successive
chunks of subprocess output, so that Emacs has enough time to return
to the idle loop and see that no new input is available.

> > If so, whether or not redisplay is called depends on the speed the
> > compilation process emits stuff that Emacs reads.  If the subprocess
> > outputs a lot of stuff,
> 
> Yes, with the document I'm using for testing, the latex process emits
> 4000 lines of text in about a 40 seconds.

The fine timing of this output's chunks is important.

> It seems that up to some point, the frequent arrival of input triggers a
> lot of redisplays, just as you explain in your other mail:
> 
> ,----
> | The arrival of subprocess output causes the pselect call to return,
> | marking the file descriptor for that process ready to be read.  Emacs
> | then reads from the descriptor, and returns to the idle loop.  If by
> | that time no additional process output arrived, Emacs will enter
> | redisplay.
> | 
> | IOW, arrival of process output is an event that causes the main loop
> | to crank one more time, and that includes redisplay.
> `----
> 
> But under some circumstances which aren't completely clear to me, the
> subprocess output paired with timers etc can cause a redisplay pause.
> The even default interval of 0.5 of b-c-m seems to play its role
> thereby.

This could happen if a very large chunk of output arrives, or several
smaller chunks arrive with almost no delay between them.  Then Emacs
will not become idle before it sees that more input is available.