Re: Removing redisplay-dont-pause

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> The problem with redisplay hangs keeps surfacing again and again, so I
>>> do expect that a number of people will try to use it as soon as they
>>> learn that such variable exists.
>>
>> The hangs you have in mind cannot be helped by this variable.
>
> I was replying about your example with scrolling. I also tested setting
> this variable when typing in an Org buffer with many large invisible
> regions, and setting the variable does help typing speed.

If you can come up with a reproducible recipe, I'd be interested to see
it, since in most cases, `redisplay-dont-pause == nil` tends to make
things worse, IME.

The way I think about it is as follows:

Assume the incoming events come every T seconds and take T1 seconds to
run, and the subsequent redisplay takes time T2+T3 (where T2 is the time
in the middle where `redisplay-dont-pause` is consulted).

Then you have the following scenarios:

- If T > T1+T2+T3, then all is well.
- If T < T1, then we plain and simply can't keep up at all, the
  redisplay is just not run at all and incoming events keep accumulating
  as we fall ever further behind the incoming events until the incoming
  events stop (at which point Emacs will only refresh its redisplay
  after it has finally caught up with the buffered input).

- If T1 < T < T1 + T2, then Emacs will keep up with the input (i.e. when
  the events stop coming, the display is refreshed more or less
  instantly) but with `redisplay-dont-pause` set to nil it will not
  refresh the display at all until the incoming events stop because
  every time it tries to redisplay it gets interrupted by some
  new input.
  If OTOH `redisplay-dont-pause` is set to t, then instead of aborting
  the redisplay, we finish it which slows us down (gets us a bit further
  behind the flow of input), but does give feedback to the user, and
  for the next few inputs we'll simply perform no redisplay at all until
  we caught up with the input, at which point we will again perform
  a redisplay, so in the end we get a redisplay after every N events
  where N = (T2 + T3) / (T - T1).
- If T1 + T2 < T < T1 + T2+ T3, the difference between the settings of
  `redisplay-dont-pause` is smaller (in both cases, the display is
  refreshed every once in a while), but there will still be fewer
  redisplays when `redisplay-dont-pause` is nil because we waste time
  starting some redisplays which we later abort.

Of course, reality is more complex (e.g. the time T2 is not a constant,
e.g. it can occasionally be proportional to the number of events since
the last redisplay), but at least in my tests where we scroll down
a buffer with a high repeat rate, the behavior matched that naïve model
closely enough.


        Stefan