From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>,
"'Juanma Barranquero'" <lekktu@gmail.com>
Cc: 8911@debbugs.gnu.org
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Wed, 29 Jun 2011 08:36:23 -0700 [thread overview]
Message-ID: <EBE9304982FA49E4A3F4AD4A7D0B7E89@us.oracle.com> (raw)
In-Reply-To: <jwvsjqtb9t5.fsf-monnier+emacs@gnu.org>
> M-x bury-buffer RET *should* iconify the current frame
> if it shows a single dedicated window (with the caveat
> that Drew wants it to delete the frame instead).
So...it *SHOULD*...(but Drew wants something different). Hm.
"Drew wants". What Drew might want for his personal use is one thing. What
Drew wants for Emacs is another thing. In either case you misrepresent what
Drew wants.
I made it clear that I did _not_ "want it to delete the frame instead". That is
_not_ the behavior I prefer for Emacs, and it is not even my preference for my
own use all of the time.
I said, speaking about the dedicated-window case:
> 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'.
NO deletion and NO iconification, by default.
That's what Drew wants for Emacs.
But also with the possibility for a _user_ to add deletion or iconification - or
anything else s?he might like. I said that we should give users control.
Users who, like Stefan, might want `bury-buffer' for a dedicated window to
always be accompanied by iconification, and users who might want it to instead
always delete the frame, should be able to get what they want.
But also users who might want `bury-buffer' to iconify in context A, delete in
context B, thumbify in context C, and do nothing at all to the display in
context D -- those users too should be able to get the behavior they prefer.
There's nothing holy about Stefan's or Drew's preferences for personal use -
those personal preferences should not preclude other users from getting other
behaviors that they prefer.
I proposed adding a `bury-buffer-hook', which users can use to do anything they
like after `bury-buffer' changes the buffer order:
> so users like Stefan can make it also do <whatever> after
> just changing the buffer order. In particular, the <whatever>
> could play with the display (iconify or delete frame etc.)
>
> Without doing anything in the hook, a dedicated
> window/frame/buffer would just stay there.
Simple, clean, easy to use, decoupled.
Flexible for different contexts.
Stefan countered with a (reluctant "Drew wants") proposal to add an option to
give users just a little control of the display behavior:
S> add an option so that bury-buffer uses delete-frame
S> instead of iconify-frame.
But he refused to let users (a) do _nothing_ in terms of display (e.g. leave the
dedicated window/frame, with its buried buffer) or (b) do something different
altogether.
The option he proposed does not let users choose any other behavior (or no
behavior), besides deletion and iconification. And naturally he wants
iconification to be the default.
My argument isn't to delete the frame.
My argument is to give the _user_ control.
My argument is that `bury-buffer' is essentially about changing the buffer
order, and any choice about what to do (if anything) about the _display_ of the
buried buffer (delete, iconify, leave alone,...) should be the _user's_ choice,
not Stefan's choice hard-wired into the design.
Even if you insisted on prepopulating the hook so that the _default_ behavior
was whatever you prefer (e.g. iconifying), what I would like is for users to
have real control over the behavior - not just some binary option to delete
instead of iconify. That's what "Drew wants".
If you refuse to give the user real control, however, and you insist on coupling
some display behavior with the changing of the buffer order (`bury-buffer's
raison d'etre), then yes, in that desperate case _only_, I said:
> _if_ the buffer is to be made to "disappear" then my (second) choice
> would be for it to disappear via `delete-frame', not iconification.
But why not let users get whatever behavior they want, easily?
Why insist on deciding for them?
We know we want `bury-buffer' to bury the buffer: change the buffer order.
That's not in question. What's not agreed upon is what else it should do,
particularly in the case of a dedicated window. I say, let users themselves
decide.
Buffer display, and especially so for dedicated windows, can be a complex,
personal matter. Please don't force automatic frame iconification (or deletion
for that matter) on everyone. There's no need for that.
next prev parent reply other threads:[~2011-06-29 15:36 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
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 [this message]
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=EBE9304982FA49E4A3F4AD4A7D0B7E89@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).