Re: Is this correct?

[Eli Zaretskii]

> From: Tim X <timx@nospam.dev.null>
> Date: Sat, 26 Feb 2011 19:59:39 +1100
> 
> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> 
> >> ,----[ C-h f force-mode-line-update RET ]
> >> | force-mode-line-update is a compiled Lisp function in `subr.el'.
> >> |
> >> | (force-mode-line-update&optional ALL)
> >> |
> >> | Force redisplay of the current buffer's mode line and header line.
> >> | With optional non-nil ALL, force redisplay of all mode lines and
> >> | header lines.  This function also forces recomputation of the
> >> | menu bar menus and the frame title.
> >> |
> >> | [back]
> >> `----
> >
> > Before digging into the details of whether the code implements the behavior
> > described in the doc string, do we understand the doc string?
> >
> > * What if the current buffer is not displayed?
> >
> 
> It isn't very clear. My assumption would be that mode-line, menu and
> header lines are irrelevant for buffers that are not displayed, so would
> assume if the current buffer is not displayed, do nothing?

Why is this an issue?  A buffer that is not displayed will have its
mode line not displayed as well.  Whether Emacs wastes CPU cycles
recomputing a mode line that isn't displayed or not should be of no
consequence to the Lisp programmer.

Or are we talking about some subtle magic that runs off mode-line
updates, which wants to be run even in buffers that are not displayed?

> > * Does ALL mean all buffers?  All windows?  All visible windows?  All 
> > frames?
> >   All visible frames?  Or some other interpretation?
> >
> 
> Yes, its not clear to me.

All buffers are considered, but only those that are displayed will
have any effect on the screen.

> > * The menu bar and frame title are frame-local, right?  If so, I think that
> >   would imply that force-mode-line-update should by default (when ALL is 
> > nil)
> >   update all displayed buffers in the current frame, and should update all
> >   displayed buffers on all frames (when ALL is non-nil).
> 
> That would seem like a reasonable interpretation. Would those other
> frames be considered visible (I've always thought so).

The menu bar is computed in the context of the current buffer, so it's
not really frame-local.

I'm not sure what does this have to do with the issue at hand, though.