[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is this correct?
Re: Is this correct?
Sun, 27 Feb 2011 09:48:24 +1100
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Eli Zaretskii <address@hidden> writes:
>> From: Tim X <address@hidden>
>> Date: Sat, 26 Feb 2011 19:59:39 +1100
>> Kevin Rodgers <address@hidden> 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.
thanks for response. I think, form the other thread where you have been
discussing this with Uday, this is probably clearer now. Just for the
We have an issue with a package that modifies the menu. After chaning
the menu, it calls force-mode-line-update. However, this is not actually
working to update the display of the menu-bar. Once the menu-bar has
been modified, some other event must occur before the menu-bar is
updated. That even could be another mouse click, movement of the cursor,
switching frames or even just waiting a minute or so (I'm guessing that
in that time, some other event triggers the update, such as updating the
load display in the mode-line, gc or something else).
To try and track this down, I was trying to understand exactly how
force-mode-line-update works and what pre-conditions it may have re:
visible/current buffers etc. So, my questions were supposed to help
clarify my understanding of both how force-update-mode-line was supposed
to work and how it actually works.
tcross (at) rapttech dot com dot au
Re: Is this correct?, Uday Reddy, 2011/02/26
Message not available