From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 'Juanma Barranquero' <lekktu@gmail.com>, 8911@debbugs.gnu.org
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Tue, 21 Jun 2011 19:53:01 -0700 [thread overview]
Message-ID: <9170F33E41584E0B8D96DD5EFC84599E@us.oracle.com> (raw)
In-Reply-To: <jwvei2mehzf.fsf-monnier+emacs@gnu.org>
> > 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.
next prev parent reply other threads:[~2011-06-22 2:53 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-21 11:01 bug#8911: bs-cycle-next deletes window in some cases Juanma Barranquero
2011-06-21 13:37 ` martin rudalics
2011-06-21 14:00 ` Juanma Barranquero
2011-06-21 14:42 ` martin rudalics
2011-06-21 15:02 ` Juanma Barranquero
2011-06-21 16:12 ` martin rudalics
2011-06-21 16:21 ` Juanma Barranquero
2011-06-21 16:28 ` Stefan Monnier
2011-06-21 16:37 ` Juanma Barranquero
2011-06-22 2:14 ` Stefan Monnier
2011-06-22 2:31 ` Juanma Barranquero
2011-06-22 20:11 ` Stefan Monnier
2011-06-21 16:22 ` Stefan Monnier
2011-06-21 16:28 ` Juanma Barranquero
2011-06-21 17:15 ` Drew Adams
2011-06-22 2:11 ` Stefan Monnier
2011-06-22 2:53 ` Drew Adams [this message]
2011-06-22 3:13 ` Drew Adams
2011-06-22 20:07 ` Stefan Monnier
2011-06-22 22:01 ` Drew Adams
2011-06-23 21:55 ` Stefan Monnier
2011-06-25 21:24 ` Juanma Barranquero
2011-06-26 9:29 ` martin rudalics
2011-06-26 11:25 ` Juanma Barranquero
2011-06-27 1:30 ` Stefan Monnier
2011-06-27 1:53 ` Juanma Barranquero
2011-06-27 7:00 ` martin rudalics
2011-06-27 9:38 ` Juanma Barranquero
2011-06-27 12:46 ` martin rudalics
2011-06-27 14:01 ` Juanma Barranquero
2011-06-27 14:12 ` martin rudalics
2011-06-27 14:22 ` Juanma Barranquero
2011-06-27 20:11 ` Juanma Barranquero
2011-06-29 3:27 ` Stefan Monnier
2011-06-29 3:57 ` Juanma Barranquero
2011-06-30 17:02 ` Stefan Monnier
2011-06-30 18:50 ` Juanma Barranquero
2011-07-01 12:07 ` Juanma Barranquero
2011-06-29 7:11 ` martin rudalics
2011-06-30 17:06 ` Stefan Monnier
2011-06-29 11:36 ` Juanma Barranquero
2011-06-29 15:36 ` Drew Adams
2011-06-29 18:21 ` Drew Adams
2011-06-30 7:00 ` martin rudalics
2011-06-30 15:31 ` Drew Adams
2011-06-22 2:07 ` Stefan Monnier
2011-06-21 16:36 ` martin rudalics
2011-06-21 17:07 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9170F33E41584E0B8D96DD5EFC84599E@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=8911@debbugs.gnu.org \
--cc=lekktu@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).