GNU bug report logs -
#8911
bs-cycle-next deletes window in some cases.
Previous Next
Full log
Message #14 received at 8911 <at> debbugs.gnu.org (full text, mbox):
>> - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',
>
> That seems to work, yes.
I think it's the correct way to handle the present case. IIUC, all
`bs-cycle-next' wants is to get the buffer out of the way in the
buffer-list. Is that assumption correct?
>> - have `bury-buffer' only delete dedicated windows as before,
>
> I don't follow you. Before that change, bury-buffer was not called
> only on dedicated windows. The trouble was that, when called on a
> dedicated window, it iconified the frame.
I stand corrected. But then the buffer shown in the dedicated window
kept its position in the buffer list. Isn't that a bug?
>> - give `bury-buffer' an extra argument which allows (or forbids) to
>> delete the selected window (or corresponding frame),
>
> Perhaps this is the best long term answer.
But it requires for each caller to guess the right approach :-(
>> - make sure that `bury-buffer' deletes only automatically created
>> windows (much like the recent option `frame-auto-delete').
>
> What's an "automatically created window"?
Those infamous windows popped up by `display-buffer'. I'm afraid that a
user of `bs-cycle-next' will hardly remember why the window was created
in the first place.
>> Earlier versions of this used
>> to iconify frames which some people on this list disliked severely so I
>> removed it. So far no one missed this issue, but maybe I shall restore
>> it as well?
>
> Again, I don't follow you. This:
>
> (progn
> (set-window-dedicated-p (selected-window) t)
> (bury-buffer))
>
> still iconifies the frame.
You're right. My memory was wandering.
martin
This bug report was last modified 13 years and 324 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.