help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is this correct?


From: Tim X
Subject: Re: Is this correct?
Date: Sun, 27 Feb 2011 09:48:24 +1100
User-agent: 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.
>
Hi Eli,

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

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.

Tim

-- 
tcross (at) rapttech dot com dot au


reply via email to

[Prev in Thread] Current Thread [Next in Thread]