Re: force-mode-line-update ALL argument

[MON KEY <monkey@sandpframing.com>]

On Sat, May 22, 2010 at 4:50 AM, martin rudalics <rudalics@gmx.at> wrote:
> Thank you for your efforts but I don't get it yet :-(

Me either. Who does?

> What makes you conclude that a `set-buffer' on the value returned by
> `other-buffer' causes updating the modeline

I trust (my assummption) that it does.
I have no way to _visually_ confirm this. Its Kantian Emacsology :P

> of a buffer that maybe has neither been changed nor displayed?

The return value of `other-buffer' is not affected by whether it has been
changed but it does affect it.

> What is a non-visible buffer on a frame?

Precisely that.

> When a buffer is visible it is on a frame.
> When a buffer is not visible it is on no frame.

From :FILE src/buffer.c

/* Switch to buffer B temporarily for redisplay purposes.
   This avoids certain things that don't need to be done within redisplay.  */

/* Move the assoc for buffer BUF to the front of buffer-alist.  Since
   we do this each time BUF is selected visibly, the more recently
   selected buffers are always closer to the front of the list.  This
   means that other_buffer is more likely to choose a relevant buffer.  */

/* Set the current buffer to B.

   We previously set windows_or_buffers_changed here to invalidate
   global unchanged information in beg_unchanged and end_unchanged.
   This is no longer necessary because we now compute unchanged
   information on a buffer-basis.  Every action affecting other
   windows than the selected one requires a select_window at some
   time, and that increments windows_or_buffers_changed.  */

> This predicate is set by a buffer change and by nothing else.

If you can't see it how can you be so sure? :P

> The only reason of updating a modeline is when the buffer is visible.

Apparently the redisplay backend doesn't share this perspective.

>
> martin, still hoping that someone can shed light on this issue
>

Good luck! :)

/s_P\