bug#10539: 24.0.92; low display-time-interval makes Emacs slow

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 27 Jan 2012 16:30:44 -0500
> Cc: 10539@debbugs.gnu.org
> 
> Michael Heerdegen wrote:
> 
> > Second, the doc of `display-time-update' says
> >
> >   Update the display-time info for the mode line.
> >   However, don't redisplay right now.
> >
> > But it _does_ redisplay, it calls `force-mode-line-update' explicitly at
> > the end of the code!
> 
> Looking at the history, the code used to have a (sit-for 0.0) after the
> force-mode-line-update. The "don't redisplay" part was added when the
> sit-for was removed. I confess that I don't really understand
> force-mode-line-update [1]. The name makes sense, but not much else.

The discussion that you refer to was about the optional ALL argument.
It said nothing about force-mode-line-update itself or its effect,
apart of that.

> The manual says:
> 
>  -- Function: force-mode-line-update &optional all
>      Force redisplay of the current buffer's mode line and header line.
>      The next redisplay will update the mode line and header line based
>      on the latest values of all relevant variables.
> 
> which seems contradictory to me ("force redisplay" + "next redisplay").

Would the following wording make it less confusing/contradictory?

  Force next redisplay cycle to update the current buffer's mode line
  and header line, based on the latest values of all the relevant
  variables.

> Maybe the "don't redisplay" refers to the lack of the ALL argument?

No, it refers to the fact that force-mode-line-update does not trigger
redisplay, it just sets some internal variable that would force
recomputation and redisplay of the mode line during the next redisplay
cycle, whenever that happens.  IOW, it prevents Emacs from deciding
that nothing changed and therefore nothing on the screen should be
redrawn.