From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: force-mode-line-update ALL argument Date: Sun, 23 May 2010 00:29:48 -0400 Message-ID: References: <4BF79AE5.6010007@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1274589005 22181 80.91.229.12 (23 May 2010 04:30:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 23 May 2010 04:30:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 23 06:30:04 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@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 1OG2p7-0004PN-HN for ged-emacs-devel@m.gmane.org; Sun, 23 May 2010 06:30:01 +0200 Original-Received: from localhost ([127.0.0.1]:45642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OG2p6-0001iy-6R for ged-emacs-devel@m.gmane.org; Sun, 23 May 2010 00:30:00 -0400 Original-Received: from [140.186.70.92] (port=45016 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OG2ox-0001hA-U5 for emacs-devel@gnu.org; Sun, 23 May 2010 00:29:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OG2ow-0000N2-1D for emacs-devel@gnu.org; Sun, 23 May 2010 00:29:51 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:44951) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OG2ov-0000Mx-V3 for emacs-devel@gnu.org; Sun, 23 May 2010 00:29:49 -0400 Original-Received: by gyg4 with SMTP id 4so1515693gyg.0 for ; Sat, 22 May 2010 21:29:49 -0700 (PDT) Original-Received: by 10.150.48.6 with SMTP id v6mr5162195ybv.39.1274588988989; Sat, 22 May 2010 21:29:48 -0700 (PDT) Original-Received: by 10.151.143.21 with HTTP; Sat, 22 May 2010 21:29:48 -0700 (PDT) In-Reply-To: <4BF79AE5.6010007@gmx.at> X-Google-Sender-Auth: o333XuJaku90dkZDey6dgh6PGOw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125097 Archived-At: On Sat, May 22, 2010 at 4:50 AM, martin rudalics 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\