Re: CVS Emacs list-buffer-noselect calls set-window-buffer, displays every buffer briefly!

[Stephan Stahl]

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