* force-mode-line-update ALL argument
@ 2010-05-20 16:53 martin rudalics
2010-05-21 6:42 ` Tassilo Horn
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2010-05-20 16:53 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
@ 2010-05-22 5:39 MON KEY
2010-05-22 8:50 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: MON KEY @ 2010-05-22 5:39 UTC (permalink / raw)
To: emacs-devel
> 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\
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
2010-05-22 5:39 MON KEY
@ 2010-05-22 8:50 ` martin rudalics
2010-05-23 4:29 ` MON KEY
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2010-05-22 8:50 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
2010-05-22 8:50 ` martin rudalics
@ 2010-05-23 4:29 ` MON KEY
2010-05-23 12:16 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: MON KEY @ 2010-05-23 4:29 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
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\
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
2010-05-23 4:29 ` MON KEY
@ 2010-05-23 12:16 ` martin rudalics
2010-05-23 17:14 ` MON KEY
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2010-05-23 12:16 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
2010-05-23 12:16 ` martin rudalics
@ 2010-05-23 17:14 ` MON KEY
2010-05-23 19:05 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: MON KEY @ 2010-05-23 17:14 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
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\
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
2010-05-23 17:14 ` MON KEY
@ 2010-05-23 19:05 ` martin rudalics
2010-05-25 2:45 ` MON KEY
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2010-05-23 19:05 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: force-mode-line-update ALL argument
2010-05-23 19:05 ` martin rudalics
@ 2010-05-25 2:45 ` MON KEY
0 siblings, 0 replies; 9+ messages in thread
From: MON KEY @ 2010-05-25 2:45 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
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\
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-05-25 2:45 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-20 16:53 force-mode-line-update ALL argument martin rudalics
2010-05-21 6:42 ` Tassilo Horn
-- strict thread matches above, loose matches on Subject: below --
2010-05-22 5:39 MON KEY
2010-05-22 8:50 ` martin rudalics
2010-05-23 4:29 ` MON KEY
2010-05-23 12:16 ` martin rudalics
2010-05-23 17:14 ` MON KEY
2010-05-23 19:05 ` martin rudalics
2010-05-25 2:45 ` MON KEY
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).