force-mode-line-update ALL argument

force-mode-line-update ALL argument

[martin rudalics]

Can someone please bother to explain the effect of setting the optional
ALL argument for `force-mode-line-update'?  I'm too silly to understand
that.

Thanks in advance, martin.

Re: force-mode-line-update ALL argument

[Tassilo Horn]

On Thursday 20 May 2010 18:53:23 martin rudalics wrote:

> Can someone please bother to explain the effect of setting the
> optional ALL argument for `force-mode-line-update'?  I'm too silly to
> understand that.

Well, the docstring is pretty clear.  But after looking at the code, I'm
at least as silly as Martin in understanding how that should work...

Bye,
Tassilo

Re: force-mode-line-update ALL argument

[MON KEY]

> at least as silly as Martin in understanding how that should work...

By making `other-buffer' the current-buffer we're effectively asking
Emacs to select some buffer which is _not_ visible and updating _its_
modeline as well if it has changed recently.  An other non-visible
buffer on the current frame which is not visible but has been modified
(a modeline change counting as such) will tickle the buffer-modified-p
predicate thereby forcing _all_ non-visible buffers on current frame
to have their modeline updated... FWICG :P

/s_P\

Re: force-mode-line-update ALL argument

[martin rudalics]

Thank you for your efforts but I don't get it yet :-(

 > By making `other-buffer' the current-buffer we're effectively asking
 > Emacs to select some buffer which is _not_ visible and updating _its_
 > modeline as well if it has changed recently.

What makes you conclude that a `set-buffer' on the value returned by
`other-buffer' causes updating the modeline of a buffer that maybe has
neither been changed nor displayed?

 > An other non-visible
 > buffer on the current frame

What is a non-visible buffer on a frame?  When a buffer is visible it is
on a frame.  When a buffer is not visible it is on no frame.

 > which is not visible but has been modified
 > (a modeline change counting as such)

What is a "modeline change" and how can it modify the buffer or count as
a buffer modification?

 > will tickle the buffer-modified-p
 > predicate

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

 > thereby forcing _all_ non-visible buffers on current frame
 > to have their modeline updated...

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

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

Re: force-mode-line-update ALL argument

[MON KEY]

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\

Re: force-mode-line-update ALL argument

[martin rudalics]

 >> 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

The entire idea is that `set-buffer' should not have an effect on the
mode line, only `set-window-buffer' should.

 >> 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.

It does affect what?

 >> 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.  */

set_buffer_temp doesn't enter here.

 > /* 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.
 >    */

record_buffer doesn't enter here either.

 > /* 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 must be the clue ;-)  In fact, this change

1999-09-02  Gerd Moellmann  <gerd@gnu.org>

	* buffer.c (set_buffer_internal): Never set
	windows_or_buffers_changed.

completely defeats the purpose of

   (if all (with-current-buffer (other-buffer)))

in `force-mode-line-update' and the ALL argument has no effect.  When
the current buffer is shown in some window, the following snippet from
Fset_buffer_modified_p

   XSETBUFFER (buffer, current_buffer);
   window = Fget_buffer_window (buffer, Qt);
   if (WINDOWP (window))
     {
       ++update_mode_lines;

asserts that _all_ modelines are updated.  If the current buffer is not
shown in any window, other modelines are not updated even if the ALL
argument has been set.  Now, usually the current buffer is shown in the
selected window, so this went by unnoticed ever since that.

 > Good luck! :)

Thanks, martin

Re: force-mode-line-update ALL argument

[MON KEY]

On Sun, May 23, 2010 at 8:16 AM, martin rudalics <rudalics@gmx.at> wrote:

> The entire idea is that `set-buffer' should not have an effect on the
> mode line, only `set-window-buffer' should.

,---- (documentation 'window-dedicated-p)
| Functions like `set-window-buffer' may change the buffer displayed
| by a window, unless that window is "strongly" dedicated to its
| buffer, that is the value returned by `window-dedicated-p' is t.
`----

IIRTC this says that `set-window-buffer' _should_ change display but
may not be depended upon to _always_ do so esp. when a window has
`strong' voodoo acting upon it.

> It does affect what?

The volatile state of transient changedness with regards intermediate
states of display.

> set_buffer_temp doesn't enter here.
>> {...}
> record_buffer doesn't enter here either.

Seriously, how can you be sure?

> in `force-mode-line-update' and the ALL argument has no effect. When
> {...}
> argument has been set.  Now, usually the current buffer is shown in
> the selected window, so this went by unnoticed ever since that.

I doubt it has gone unnoticed for 10+ years.  More likely no one was
brave enough to assert that Fset_buffer_modified_p et al cover _all_
cases.

Maybe you are the Obeah man willing to oust these demon zombies.
There is much voodo in the (re)display engine. How powerful is your
juju? May I suggest you keep some chickens handy for sacrificial
offerings :)

> Thanks, martin

/s_P\

Re: force-mode-line-update ALL argument

[martin rudalics]

 >> The entire idea is that `set-buffer' should not have an effect on the
 >> mode line, only `set-window-buffer' should.
 >
 > ,---- (documentation 'window-dedicated-p)
 > | Functions like `set-window-buffer' may change the buffer displayed
 > | by a window, unless that window is "strongly" dedicated to its
 > | buffer, that is the value returned by `window-dedicated-p' is t.
 > `----
 >
 > IIRTC this says that `set-window-buffer' _should_ change display but
 > may not be depended upon to _always_ do so esp. when a window has
 > `strong' voodoo acting upon it.

How would this relate to the issue at hand?

 >> set_buffer_temp doesn't enter here.
 >>> {...}
 >> record_buffer doesn't enter here either.
 >
 > Seriously, how can you be sure?

Because I studied the code.

 >> in `force-mode-line-update' and the ALL argument has no effect. When
 >> {...}
 >> argument has been set.  Now, usually the current buffer is shown in
 >> the selected window, so this went by unnoticed ever since that.
 >
 > I doubt it has gone unnoticed for 10+ years.  More likely no one was
 > brave enough to assert that Fset_buffer_modified_p et al cover _all_
 > cases.

A "bug" occurs iff you call `force-mode-line-update' in a state where
the current buffer is not shown in any window.  Why should anyone want
to do that?

martin

Re: force-mode-line-update ALL argument

[MON KEY]

On Sun, May 23, 2010 at 3:05 PM, martin rudalics <rudalics@gmx.at> wrote:
> How would this relate to the issue at hand?

If I understand what is at issue, any code (lisp-side or C-side) that
interacts with buffer state has to set buffers modified (unless the
``strongly'' vodoo is in effect) whenever changes take place. This is
(or may sometimes be) one aspect of a series of actions which need
occur when a buffer is in a state of frob'dness.

> Because I studied the code.

Wow! So you are sure.

> the current buffer is not shown in any window.  Why should anyone want
> to do that?

No clue. Maybe they haven't studied the code.  :)

> martin

/s_P\