From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: Is this correct? Date: Sun, 27 Feb 2011 09:48:24 +1100 Organization: Unlimited download news at news.astraweb.com Message-ID: <87d3me76pz.fsf@puma.rapttech.com.au> References: <87tyfrp9p2.fsf@puma.rapttech.com.au> <87lj136uis.fsf@puma.rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1298763635 5262 80.91.229.12 (26 Feb 2011 23:40:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Feb 2011 23:40:35 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Feb 27 00:40:31 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PtTkU-0006SC-CC for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Feb 2011 00:40:30 +0100 Original-Received: from localhost ([127.0.0.1]:44161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtTkT-0005wp-Uj for geh-help-gnu-emacs@m.gmane.org; Sat, 26 Feb 2011 18:40:29 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.astraweb.com!border6.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:t3XHvTBdLtlxr3X5v5EVqz33x0I= Original-Lines: 85 Original-NNTP-Posting-Host: 2499495a.news.astraweb.com Original-X-Trace: DXC=UdOD?34gGRBU8fT?_VL23KL?0kYOcDh@JN7:H2`MmAUCF8TiH9LRjfA]G; 2>V^?kWCCAkl5c@XgkN6GAWCS[`KSD=g0WS:mY9kB Original-Xref: usenet.stanford.edu gnu.emacs.help:185356 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:79512 Archived-At: Eli Zaretskii writes: >> From: Tim X >> Date: Sat, 26 Feb 2011 19:59:39 +1100 >> >> Kevin Rodgers 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