GNU bug report logs - #8911
bs-cycle-next deletes window in some cases.

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Tue, 21 Jun 2011 11:03:01 UTC

Severity: normal

Done: Juanma Barranquero <lekktu <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Juanma Barranquero' <lekktu <at> gmail.com>, 8911 <at> debbugs.gnu.org
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Tue, 21 Jun 2011 19:53:01 -0700
> > I would like `bury-buffer' to be decoupled from 
> > iconification.  I would like `bury-buffer' to do
> > nothing particular wrt dedicated windows.
> 
> I'm not sure what "particular" means here.

I explained what it means in the earlier mail:

| [from the doc string:]
|
|  "Also, if BUFFER-OR-NAME is nil or omitted,
|   remove the current buffer from the selected window
|   if it is displayed there."
|
| It is impossible to "remove the current buffer from the
| selected window" if that window is dedicated, so this
| secondary behavior naturally becomes a no-op in that case.
|
| If the window is dedicated, then I'd rather see one of
| these behaviors than I would iconification of the buffer's
| frame:
|
| a. Do nothing wrt the display.  See above: a no-op wrt display.
| b. Delete the frame.
|
| Perhaps the best approach is (a) above: have `bury-buffer'
| just bury the buffer (i.e. affect the buffer order) and
| not have it do anything wrt the display in this case.

IOW, not disappear or move in any way - an unchanged display.  The only effect
would be the change in buffer order that is the raison d'etre of `bury-buffer':
make it least likely to be used as `other-buffer'.

> Part of the drive behind iconification is that I want
> bury-buffer to be a sort of reverse-display-buffer,

As I also said earlier, to me (and per the doc string and the function's past
behavior) `bury-buffer' is not about display.  (That is, it is only secondarily
about display, and only in the one particular case quoted above.)

`bury-buffer' is about reducing the priority of the buffer in the buffer order -
e.g., for `other-buffer'.

Of course display can come into play later, when `other-buffer' (or some other
function) does its thing, which can involve display.  But `bury-buffer' should
not be about affecting the current display of buffers, except in the one case
documented.  At least that would be my preference, I think.

For the case in question (dedicated), if the buffer is to be made to "disappear"
then my (second) choice would be for it to disappear via `delete-frame', not
iconification.

The reason is primarily the annoyance that iconifying can produce - on Windows
it is kind of animated, essentially sweeping across the display down to the task
bar.  With frame deletion it just disappears instantly - poof.

> such that display-buffer followed by bury-buffer should be
> a no-op (I know it's not always the case), so as to replace
> save-window-excursion with something that does not impose
> nesting and that works with frames.





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.