From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stephan Stahl" Newsgroups: gmane.emacs.devel Subject: Re: CVS Emacs list-buffer-noselect calls set-window-buffer, displays every buffer briefly! Date: Fri, 3 Sep 2004 08:27:23 +0200 (CEST) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <51975.217.194.34.123.1094192843.squirrel@wwws.franken.de> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Trace: sea.gmane.org 1094192884 10715 80.91.224.253 (3 Sep 2004 06:28:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Sep 2004 06:28:04 +0000 (UTC) Cc: Francis Litterio , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 03 08:27:54 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C37Y9-0005O6-00 for ; Fri, 03 Sep 2004 08:27:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C37d9-0003ze-V8 for ged-emacs-devel@m.gmane.org; Fri, 03 Sep 2004 02:33:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C37d4-0003zZ-BD for emacs-devel@gnu.org; Fri, 03 Sep 2004 02:32:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C37d3-0003zN-1s for emacs-devel@gnu.org; Fri, 03 Sep 2004 02:32:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C37d3-0003zK-0G for emacs-devel@gnu.org; Fri, 03 Sep 2004 02:32:57 -0400 Original-Received: from [193.175.24.27] (helo=ilsa.franken.de) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1C37Xi-0007hJ-Tu for emacs-devel@gnu.org; Fri, 03 Sep 2004 02:27:27 -0400 Original-Received: from wwws.franken.de (mail-n.franken.de [193.175.24.27]) by ilsa.franken.de (Postfix) with SMTP id BB5E5245CF; Fri, 3 Sep 2004 08:27:22 +0200 (CEST) Original-Received: from 217.194.34.123 (SquirrelMail authenticated user eos) by wwws.franken.de with HTTP; Fri, 3 Sep 2004 08:27:23 +0200 (CEST) In-Reply-To: Original-To: "Stefan Monnier" User-Agent: SquirrelMail/1.4.0 X-Priority: 3 Importance: Normal 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26745 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26745 Hi Stefan, Francis. Stefan Monnier said: >>>> (set-window-buffer (selected-window) buffer) >>>> once for every buffer while building the buffer menu. On my Windows >>>> XP >>>> machine, this makes Emacs briefely display every buffer for a fraction >>> >>> Isn't it a bug that a redisplay would happen in that loop? >>> Which function in that loop lets redisplay happen? > >> It's definitely set-window-buffer, because when I remove the call to >> that function, the symptom goes away. That line in list-buffer-noselect was introduced by a patch from me. Revision 1.67: (list-buffers-noselect): Append the buffer's process status to its mode name. If it is removed the following code in buff-menu.el will not work correctly: mode (progn (set-window-buffer (selected-window) buffer) (concat (format-mode-line mode-name) (if mode-line-process (format-mode-line mode-line-process)))) file (buffer-file-name))) format-mode-line will only work correctly if it is called while the buffer is selected. A way to reproduce the bug is: remove that line. start two shells. kill one of them and do C-x C-b. Now the added information about the process status is not correct. If you do C-x C-b from the running shell both are shown with ":run". From the killed shell both will show ":exit [0]". In fact that will be that case for all buffers with a process.. > It might be, but it's not necessarily the case: in Emacs, redisplay is > a separate operation from "changes to the buffer or the window layout". > `set-window-buffer' changes the window-layout which means it changes "what > will be displayed at next redisplay" but it shouldn't call > redisplay itself. > > My question is not directly related to your problem, in the sense that > I think your patch is OK (except it should add a comment explaining why we > removed the call to set-window-buffer), but I think that your problem also > exposed another bug in the C code. I tested my patch on both Debian GNU/Linux and WXP. Maybe i did not look close enough to notice that bug. I think we should try to find it and only if that fails revert my patch.. Stephan -- Stephan Stahl