* bug#8911: bs-cycle-next deletes window in some cases. @ 2011-06-21 11:01 Juanma Barranquero 2011-06-21 13:37 ` martin rudalics 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-21 11:01 UTC (permalink / raw) To: 8911 With current trunk. emacs -Q -l bs C-x 2 M-x bs-cycle-next <RET> and the bottom window is deleted. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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 0 siblings, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-21 13:37 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > With current trunk. > > emacs -Q -l bs > C-x 2 > M-x bs-cycle-next <RET> > > and the bottom window is deleted. IIUC this happens because of this code (unless (window-dedicated-p (selected-window)) ;; We don't want the frame iconified if the only window in the frame ;; happens to be dedicated; let's get the error from switch-to-buffer (bury-buffer)) (switch-to-buffer next) in `bs-cycle-next' and `bury-buffer' can now delete a window showing the buffer provided this buffer was the first to appear in a window. `bs-cycle-next' is probably not to blame because it just wants to make sure that the buffer is not chosen again soon for displaying it. So we have a number of ways to restore the old behavior, namely - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer', - have `bury-buffer' only delete dedicated windows as before, - give `bury-buffer' an extra argument which allows (or forbids) to delete the selected window (or corresponding frame), - make sure that `bury-buffer' deletes only automatically created windows (much like the recent option `frame-auto-delete'). Personally, I have no preference since I never understood the "additional" semantics of `bury-buffer'. 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? martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 13:37 ` martin rudalics @ 2011-06-21 14:00 ` Juanma Barranquero 2011-06-21 14:42 ` martin rudalics 2011-06-21 16:22 ` Stefan Monnier 0 siblings, 2 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-21 14:00 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 On Tue, Jun 21, 2011 at 15:37, martin rudalics <rudalics@gmx.at> wrote: > `bs-cycle-next' is probably not to blame because it just wants to make > sure that the buffer is not chosen again soon for displaying it. So we > have a number of ways to restore the old behavior, namely > > - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer', That seems to work, yes. > - 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. > - 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. > - make sure that `bury-buffer' deletes only automatically created > windows (much like the recent option `frame-auto-delete'). What's an "automatically created window"? > 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. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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:22 ` Stefan Monnier 1 sibling, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-21 14:42 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> - 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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:28 ` Stefan Monnier 0 siblings, 2 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-21 15:02 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 On Tue, Jun 21, 2011 at 16:42, martin rudalics <rudalics@gmx.at> wrote: > 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? If you ask about the reason to call `bury-buffer' at that point, yes. The reason to call `bs-cycle-next' is to rotate among the buffers in the current window. > I stand corrected. But then the buffer shown in the dedicated window > kept its position in the buffer list. Isn't that a bug? If the window is dedicated, and the user invokes bs-cycle-next (usually, by having it bound to a key, and not realizing that the window is dedicated), that's user error, but the user should not be penalized; staying is better. Perhaps a message could be shown. Also, no new window should be created. For example, I find the current behavior emacs -Q -l bs C-h N C-h C-c M-: (set-window-dedicated-p (selected-window) t) <RET> M-x bs-cycle-next <RET> of splitting the window extremely unuseful and unhelpful. Let's say that I'm an extreme case of not wanting non-temporary windows unless I create them myself explicitly. > 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. Definitely. > You're right. My memory was wandering. Well, not that I have refreshed it, it would be good if that wouldn't iconify the frame ;-) Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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 1 sibling, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-21 16:12 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > If the window is dedicated, and the user invokes bs-cycle-next > (usually, by having it bound to a key, and not realizing that the > window is dedicated), that's user error, but the user should not be > penalized; staying is better. Perhaps a message could be shown. Also, > no new window should be created. For example, I find the current > behavior > > emacs -Q -l bs > C-h N > C-h C-c > M-: (set-window-dedicated-p (selected-window) t) <RET> > M-x bs-cycle-next <RET> > > of splitting the window extremely unuseful and unhelpful. Because it does (switch-to-buffer next) in `bs-cycle-next'? Well, what else should it do? Undedicate the window? That is a tricky case. martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 16:12 ` martin rudalics @ 2011-06-21 16:21 ` Juanma Barranquero 0 siblings, 0 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-21 16:21 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 On Tue, Jun 21, 2011 at 18:12, martin rudalics <rudalics@gmx.at> wrote: > Because it does (switch-to-buffer next) in `bs-cycle-next'? Well, what > else should it do? Undedicate the window? That is a tricky case. Fail, i.e., do nothing (except displaying a message). BTW, I'm not saying that switch-to-buffer should do nothing, I'm saying that I expect bs-cycle-next to do nothing in such case. The current behavior is not "cycling". But this is unrelated to your changes, it already happens in 23.X. I'm more interested in fixing the original problem. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 15:02 ` Juanma Barranquero 2011-06-21 16:12 ` martin rudalics @ 2011-06-21 16:28 ` Stefan Monnier 2011-06-21 16:37 ` Juanma Barranquero 2011-06-22 2:14 ` Stefan Monnier 1 sibling, 2 replies; 48+ messages in thread From: Stefan Monnier @ 2011-06-21 16:28 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> I stand corrected. But then the buffer shown in the dedicated window >> kept its position in the buffer list. Isn't that a bug? Yes, tho it's probably minor. > If the window is dedicated, and the user invokes bs-cycle-next > (usually, by having it bound to a key, and not realizing that the > window is dedicated), that's user error, but the user should not be Not if the window is softly-dedicated (in which case the window should be un-dedicated). > no new window should be created. For example, I find the current > behavior > emacs -Q -l bs > C-h N > C-h C-c > M-: (set-window-dedicated-p (selected-window) t) <RET> > M-x bs-cycle-next <RET> > of splitting the window extremely unuseful and unhelpful. But that's the semantics of (set-window-dedicated-p (selected-window) t). If you don't like it, then you should use (set-window-dedicated-p (selected-window) 'soft) instead. >> 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. > Definitely. That's the whole idea behind soft-dedication. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 16:28 ` Stefan Monnier @ 2011-06-21 16:37 ` Juanma Barranquero 2011-06-22 2:14 ` Stefan Monnier 1 sibling, 0 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-21 16:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Tue, Jun 21, 2011 at 18:28, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> If the window is dedicated, and the user invokes bs-cycle-next >> (usually, by having it bound to a key, and not realizing that the >> window is dedicated), that's user error, but the user should not be > > Not if the window is softly-dedicated (in which case the window should > be un-dedicated). Yes, I'm talking of strong dedication. > But that's the semantics of (set-window-dedicated-p (selected-window) t). > If you don't like it, then you should use > (set-window-dedicated-p (selected-window) 'soft) instead. The semantics of strong dedication is not entirely clear to me, but I'd say it is more about what happens to the window/buffer correspondence, that what happens in other windows or to other buffers. In other words, if I make a window strongly dedicated I'm not saying I what I do want about other buffers or other windows, I'm only saying "I don't want other buffers in this window". I agree cases are not always clear cut, and I suppose that in other situations I would find the behavior that you describe quite logical. Not so for bs-cycle-next, whose purpose is to cycle buffers in the current window (I should know, I was the one to propose these commands to Olaf Sylvester quite a few years ago, and judging by the ChangeLogs I'm the main user of bs.el among the Emacs developers ;-) Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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 1 sibling, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2011-06-22 2:14 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> emacs -Q -l bs >> C-h N >> C-h C-c >> M-: (set-window-dedicated-p (selected-window) t) <RET> >> M-x bs-cycle-next <RET> >> of splitting the window extremely unuseful and unhelpful. > But that's the semantics of (set-window-dedicated-p (selected-window) t). Sorry, you're right. The right thing to do here is to signal an error, not to split the window. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-22 2:14 ` Stefan Monnier @ 2011-06-22 2:31 ` Juanma Barranquero 2011-06-22 20:11 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-22 2:31 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Wed, Jun 22, 2011 at 04:14, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Sorry, you're right. The right thing to do here is to signal an error, > not to split the window. That's what it did until 22.3; it displayed "Cannot switch buffers in a dedicated window". Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-22 2:31 ` Juanma Barranquero @ 2011-06-22 20:11 ` Stefan Monnier 0 siblings, 0 replies; 48+ messages in thread From: Stefan Monnier @ 2011-06-22 20:11 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> Sorry, you're right. The right thing to do here is to signal an error, >> not to split the window. > That's what it did until 22.3; it displayed "Cannot switch buffers in > a dedicated window". I know, I'm to blame for the change in Emacs-23, where I made switch-to-buffer fallback to pop-up-buffer when used in a dedicated window. I'll gladly admit that this fallback is wrong, but it's the sanest way I've found to deal with the wealth of packages calling switch-to-buffer because the author didn't know better. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 14:00 ` Juanma Barranquero 2011-06-21 14:42 ` martin rudalics @ 2011-06-21 16:22 ` Stefan Monnier 2011-06-21 16:28 ` Juanma Barranquero ` (2 more replies) 1 sibling, 3 replies; 48+ messages in thread From: Stefan Monnier @ 2011-06-21 16:22 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > The trouble was that, when called on a dedicated window, it iconified > the frame. I don't follow: why do you think it's a trouble? To me it's exactly what I want. Is it that you prefer it deletes the frame rather than iconify it? >> - 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. Not sure if it's needed. Calling bury-buffer with a non-nil arg should be sufficient. >> - make sure that `bury-buffer' deletes only automatically created >> windows (much like the recent option `frame-auto-delete'). > What's an "automatically created window"? Good question. To me it sounds like "softly dedicated" windows, but I know Martin hates those, so he is clearly thinking of something else. > (progn > (set-window-dedicated-p (selected-window) t) > (bury-buffer)) > still iconifies the frame. What else would you want it to do? Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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:07 ` Stefan Monnier 2011-06-21 16:36 ` martin rudalics 2011-06-21 17:07 ` Drew Adams 2 siblings, 2 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-21 16:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Tue, Jun 21, 2011 at 18:22, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I don't follow: why do you think it's a trouble? To me it's exactly > what I want. Is it that you prefer it deletes the frame rather than > iconify it? No, certainly no. >> (progn >> (set-window-dedicated-p (selected-window) t) >> (bury-buffer)) > >> still iconifies the frame. > > What else would you want it to do? Nothing, other than a message to the user "Attempt to bury buffer in dedicated window", or something more friendly but equivalent. "burying a buffer" /= "iconifying a frame". The fact that the window is dedicated does not turn that difference suddenly into an equality. Please note a difference between your use of Emacs and mine: I *never* use multiple frames. So if I happen to have a dedicated window and I accidentaly try to bury the buffer, iconifying my only frame is never, ever going to be useful. It will *always* be followed by de-iconifying it and then fixing the problem. Of course, it's not often that I have a single, dedicated window in the frame. But I use dedicated windows for some things (like the output of bs-show), and I sometimes do C-x 1 while on one of these buffers. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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:07 ` Stefan Monnier 1 sibling, 1 reply; 48+ messages in thread From: Drew Adams @ 2011-06-21 17:15 UTC (permalink / raw) To: 'Juanma Barranquero', 'Stefan Monnier'; +Cc: 8911 > > I don't follow: why do you think it's a trouble? To me it's exactly > > what I want. Is it that you prefer it deletes the frame rather than > > iconify it? > > No, certainly no. > > >> still iconifies the frame. > > What else would you want it to do? > > Nothing, other than a message to the user "Attempt to bury buffer in > dedicated window", or something more friendly but equivalent. > > "burying a buffer" /= "iconifying a frame". The fact that the window > is dedicated does not turn that difference suddenly into an equality. > > Please note a difference between your use of Emacs and mine: I *never* > use multiple frames. FWIW, I typically use multiple frames, and typically with a single buffer each. Most of my frames are not dedicated, but a few are. Nevertheless, I agree with Juanma here. For my purposes, iconification would always be wrong as part of the behavior of `bury-buffer'. IIUC, Stefan also uses frames a lot, but he typically (always?) uses (soft-)dedicated windows. And he uses a different OS from me, so iconification might be less annoying for him. I would like `bury-buffer' to be decoupled from iconification. I would like `bury-buffer' to do nothing particular wrt dedicated windows. Another caveat: I know little about soft-dedication. Perhaps that makes a difference to understanding this issue. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 17:15 ` Drew Adams @ 2011-06-22 2:11 ` Stefan Monnier 2011-06-22 2:53 ` Drew Adams 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2011-06-22 2:11 UTC (permalink / raw) To: Drew Adams; +Cc: 'Juanma Barranquero', 8911 > 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. Part of the drive behind iconification is that I want bury-buffer to be a sort of reverse-display-buffer, 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. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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 0 siblings, 2 replies; 48+ messages in thread From: Drew Adams @ 2011-06-22 2:53 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 'Juanma Barranquero', 8911 > > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-22 2:53 ` Drew Adams @ 2011-06-22 3:13 ` Drew Adams 2011-06-22 20:07 ` Stefan Monnier 1 sibling, 0 replies; 48+ messages in thread From: Drew Adams @ 2011-06-22 3:13 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 'Juanma Barranquero', 8911 > 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'. > > `bury-buffer' is not about display.... `bury-buffer' is about > reducing the priority of the buffer in the buffer order - > e.g., for `other-buffer'. Here's another idea: Have `bury-buffer', as I suggested, do nothing wrt display, but add a hook for it, 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 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 1 sibling, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2011-06-22 20:07 UTC (permalink / raw) To: Drew Adams; +Cc: 'Juanma Barranquero', 8911 > 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.) There are two ways to call bury-buffer, which correspond to two fairly different behaviors. One is with a non-nil argument, where it only touches the order in the buffer-list. This one is uncontroversial and doesn't matter much to me. The other is when the argument is nil, in which case it is *specifically* meant to make the buffer disappear (additionally to changing the buffer-list order). This case is very much about display, not just secondarily so. > 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. Then we could add an option so that bury-buffer uses delete-frame instead of iconify-frame. But doing nothing is not an option since the caller specifically asked to undisplay the buffer. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-22 20:07 ` Stefan Monnier @ 2011-06-22 22:01 ` Drew Adams 2011-06-23 21:55 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2011-06-22 22:01 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 'Juanma Barranquero', 8911 > > 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.) > > There are two ways to call bury-buffer, which correspond to two fairly > different behaviors. One is with a non-nil argument, where it only > touches the order in the buffer-list. This one is uncontroversial and > doesn't matter much to me. Right. Glad that at least in this case you're OK with not doing anything wrt display. > The other is when the argument is nil, in which case it is > *specifically* meant to make the buffer disappear I'm sure I won't be able to convince you, but that is not what the doc string indicates. It speaks only about removing the current buffer _from the selected window_ (if displayed there). To you maybe that suggests something about "disappearing" in the case of a dedicated window. To me it suggests nothing of the kind. To me it suggests on the contrary that this is not at all about that particular case, but is instead _ONLY_ about the case where the buffer _CAN_ be removed from the window. To me, that sentence, which has been around since Day One, covers only the special case that does _not_ include dedicated windows, since the current buffer cannot be removed from such a window. Dedicated windows have also been around a long time, yet the `bury-buffer' doc never said anything about doing anything to a dedicated window or its frame. Never UNTIL, that is, Emacs 23, when you (Emacs Dev) changed it - in the manual. You added this: "But if the selected window is dedicated to its buffer, it deletes that window if there are other windows left on its frame. Otherwise, if the selected window is the only window on its frame, it iconifies that frame." That was never the behavior or the interpretation (doc) before that. AFAIK, before Emacs 23 `bury-buffer' never did anything about the window in the dedicated case. It certainly never made the buffer "disappear" in any way for that case. Instead, it raised the error "Cannot switch buffers in a dedicated window", which to me sounds right. No doubt you consider that previous behavior a bug, but I expect it was by design, and I think it was not a bad choice. > (additionally to changing the buffer-list order). This case is > very much about display, not just secondarily so. Not for the dedicated case - not until Emacs 23, that is. That behavior was grafted on, and IMO it was a mistake. > > 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. > > Then we could add an option so that bury-buffer uses delete-frame > instead of iconify-frame. Or `ignore' instead of `iconify-frame'... But why not instead do as I suggested earlier: 1. Return to the pre-23 behavior, so that `bury-buffer' is once again not about display. 2. Add a `bury-buffer-hook', to let people tack on any behavior they like, whether related to display or not. You might tack on `iconify-frame'. I might (or might not) tack on `delete-frame'. Joe Lambda might tack on a logging function to record buffer activity or something. I agree that it will not be uncommon to want to associate some display behavior with `bury-buffer'. I don't think the right idea is to try to decide on one display behavior that fits all. And I would opt for a hook (keeping `bury-buffer' display-free) rather than an option whose default value is some display behavior (e.g. `iconify-frame'). > But doing nothing is not an option since the caller > specifically asked to undisplay the buffer. Not until you changed the meaning to that. A caller of `bury-buffer' wants to change the buffer order. Why mix in additional behavior, so that a caller must now "want" to do a particular mix of things that don't necessarily go together? FWIW. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-22 22:01 ` Drew Adams @ 2011-06-23 21:55 ` Stefan Monnier 2011-06-25 21:24 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2011-06-23 21:55 UTC (permalink / raw) To: Drew Adams; +Cc: 'Juanma Barranquero', 8911 > I'm sure I won't be able to convince you, but that is not what the doc > string indicates. It speaks only about removing the current buffer > _from the selected window_ (if displayed there). > To you maybe that suggests something about "disappearing" in the case > of a dedicated window. > To me it suggests nothing of the kind. To me it suggests on the > contrary that this is not at all about that particular case, but is > instead _ONLY_ about the case where the buffer _CAN_ be removed from > the window. Indeed you won't be able to convince me. I know enough about the way bury-buffer is used throughout the Emacs code to know what is the intended behavior. > Instead, it raised the error "Cannot switch buffers in a dedicated window", > which to me sounds right. If "breaks most calls to bury-buffer when the window is dedicated" sounds right to you, then I guess I won't be able to convince you either. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-23 21:55 ` Stefan Monnier @ 2011-06-25 21:24 ` Juanma Barranquero 2011-06-26 9:29 ` martin rudalics 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-25 21:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 Several bugs related to bury-buffer have been discussed in this thread: - bs-cycle-next deleting a window - bs-cycle-next creating a window is the current one is dedicated - bury-buffer unexpectedly iconizing a frame but I'm not sure whether some consensus was reached with respect to how, and where, to fix them. So I'm pinging to get the ball rolling again. J ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-25 21:24 ` Juanma Barranquero @ 2011-06-26 9:29 ` martin rudalics 2011-06-26 11:25 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-26 9:29 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > - bs-cycle-next deleting a window I thought Stefan's proposal to call `bury-buffer' with the current buffer as explicit argument should handle this. martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-26 9:29 ` martin rudalics @ 2011-06-26 11:25 ` Juanma Barranquero 2011-06-27 1:30 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-26 11:25 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 > I thought Stefan's proposal to call `bury-buffer' with the current > buffer as explicit argument should handle this. True, thanks. I've committed that fix. What about the other two? Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-26 11:25 ` Juanma Barranquero @ 2011-06-27 1:30 ` Stefan Monnier 2011-06-27 1:53 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2011-06-27 1:30 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> I thought Stefan's proposal to call `bury-buffer' with the current >> buffer as explicit argument should handle this. > True, thanks. I've committed that fix. > What about the other two? I'm not sure about the third (isn't it also fixed by passing a non-nil arg to bury-buffer?), but for the second the right fix is to remove the "fallback on pop-to-buffer" from switch-to-buffer. Of course, that will (re)introduce new bugs which we could/should "fix" by marking switch-to-buffer (and find-file and maybe a few more) as "don't call from Elisp". Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 1:30 ` Stefan Monnier @ 2011-06-27 1:53 ` Juanma Barranquero 2011-06-27 7:00 ` martin rudalics 2011-06-29 3:27 ` Stefan Monnier 0 siblings, 2 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-27 1:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Mon, Jun 27, 2011 at 03:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I'm not sure about the third (isn't it also fixed by passing a non-nil > arg to bury-buffer?) Well, yes, but that means "fixing" it everywhere; I mean: emacs -Q M-: (set-window-dedicated-p (selected-window) t) <RET> M-x bury-buffer <RET> and the frame is iconified. It shouldn't. > but for the second the right fix is to remove the > "fallback on pop-to-buffer" from switch-to-buffer. Of course, that will > (re)introduce new bugs which we could/should "fix" by marking > switch-to-buffer (and find-file and maybe a few more) as "don't call > from Elisp". If switch-to-buffer is changed not to fallback on pop-to-buffer, why shouldn't it be called from elisp? In the case of bs-cycle-next: (unless (window-dedicated-p (selected-window)) ;; We don't want the frame iconified if the only window in the frame ;; happens to be dedicated (bury-buffer (current-buffer))) (switch-to-buffer next) the current switch-to-buffer causes the unwanted-splitting behavior. Changing it to pop-to-buffer-same-window, as its docstring suggests, would still cause the same problem. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 1:53 ` Juanma Barranquero @ 2011-06-27 7:00 ` martin rudalics 2011-06-27 9:38 ` Juanma Barranquero 2011-06-29 3:27 ` Stefan Monnier 1 sibling, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-27 7:00 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > If switch-to-buffer is changed not to fallback on pop-to-buffer, why > shouldn't it be called from elisp? In the case of bs-cycle-next: > > (unless (window-dedicated-p (selected-window)) > ;; We don't want the frame iconified if the only window in the frame > ;; happens to be dedicated > (bury-buffer (current-buffer))) > (switch-to-buffer next) > > the current switch-to-buffer causes the unwanted-splitting behavior. > Changing it to pop-to-buffer-same-window, as its docstring suggests, > would still cause the same problem. `switch-to-buffer' has a specific window show a specific buffer. The user cannot change that via options. `pop-to-buffer-same-window' tries to show a specific buffer in a specific window. But the user can change that via options. In particular, the user can decide to override the splitting behavior, dedicatedness of windows, ... All `bs-cycle-next' has to do is call it via (pop-to-buffer-same-window next nil 'bs-cycle-next) martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 7:00 ` martin rudalics @ 2011-06-27 9:38 ` Juanma Barranquero 2011-06-27 12:46 ` martin rudalics 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-27 9:38 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 On Mon, Jun 27, 2011 at 09:00, martin rudalics <rudalics@gmx.at> wrote: > `switch-to-buffer' has a specific window show a specific buffer. The > user cannot change that via options. Understood. > `pop-to-buffer-same-window' tries to show a specific buffer in a > specific window. But the user can change that via options. In > particular, the user can decide to override the splitting behavior, > dedicatedness of windows, ... In the specific case of bs-cycle-next, for non-dedicated windows, (pop-to-buffer-same-window next) works. > All `bs-cycle-next' has to do is call > it via > > (pop-to-buffer-same-window next nil 'bs-cycle-next) Presumably you mean all is needed is that, plus an entry in `display-buffer-alist'. But I don't see a way to say "OK, abort, this window is strongly dedicated so the buffer shouldn't be shown anywhere, just throw an error to the user". Care to show how to say that? TIA, Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 9:38 ` Juanma Barranquero @ 2011-06-27 12:46 ` martin rudalics 2011-06-27 14:01 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-27 12:46 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > Presumably you mean all is needed is that, plus an entry in > `display-buffer-alist'. If the user wants to change the default behavior, yes. > But I don't see a way to say "OK, abort, this > window is strongly dedicated so the buffer shouldn't be shown > anywhere, just throw an error to the user". Care to show how to say > that? I'm not sure whether we want to do that. If so, there are two ways. Either, in `bs-cycle-next' write something like: (if (and (window-dedicated-p) (not (eq (window-buffer) next))) (error "Selected window is dedicated to its buffer") (display-buffer-same-window next)) which gives the user no choice wrt what to do when the selected window is dedicated or write (defun reuse-same-window-unless-dedicated (buffer &rest args) "..." (if (and (window-dedicated-p) (not (eq (window-buffer) next))) (error "Selected window is dedicated to its buffer") (display-buffer-same-window buffer))) (display-buffer next '((fun-with-args reuse-same-window-unless-dedicated)) 'bs-cycle-next) and allow the user to specify her own deviant behavior when the selected window is dedicated. martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 12:46 ` martin rudalics @ 2011-06-27 14:01 ` Juanma Barranquero 2011-06-27 14:12 ` martin rudalics 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-27 14:01 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 On Mon, Jun 27, 2011 at 14:46, martin rudalics <rudalics@gmx.at> wrote: > If the user wants to change the default behavior, yes. Ah. Current documentation for display-buffer-alist is less than clear to me. > I'm not sure whether we want to do that. Well, I'm not sure whether *we* want, either, but I'm definitely sure I want (locally, I mean). > If so, there are two ways. > Either, in `bs-cycle-next' write something like: > > (if (and (window-dedicated-p) (not (eq (window-buffer) next))) > (error "Selected window is dedicated to its buffer") > (display-buffer-same-window next)) > > which gives the user no choice wrt what to do when the selected window > is dedicated I supose this is a no-no. > or write > > (defun reuse-same-window-unless-dedicated (buffer &rest args) > "..." > (if (and (window-dedicated-p) (not (eq (window-buffer) next))) > (error "Selected window is dedicated to its buffer") > (display-buffer-same-window buffer))) > > (display-buffer > next '((fun-with-args reuse-same-window-unless-dedicated)) 'bs-cycle-next) > > and allow the user to specify her own deviant behavior when the selected > window is dedicated. I don't follow you. reuse-same-window-unless-dedicated is throwing an error unconditionally. How would the user specifiy her own behavior? Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 14:01 ` Juanma Barranquero @ 2011-06-27 14:12 ` martin rudalics 2011-06-27 14:22 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-27 14:12 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > I don't follow you. reuse-same-window-unless-dedicated is throwing an > error unconditionally. How would the user specifiy her own behavior? Using the override specifier and matching the bs-cycle-next label. The override specifier should do what it says - override everything the application proposes. The label is needed since `bs-cycle-next' can pop up an arbitrary buffer no regexp or name could selectively match. martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 14:12 ` martin rudalics @ 2011-06-27 14:22 ` Juanma Barranquero 2011-06-27 20:11 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-27 14:22 UTC (permalink / raw) To: martin rudalics; +Cc: 8911 On Mon, Jun 27, 2011 at 16:12, martin rudalics <rudalics@gmx.at> wrote: > Using the override specifier and matching the bs-cycle-next label. The > override specifier should do what it says - override everything the > application proposes. I'm quite sure I will be able to do that, as soon as I'm able to understand display-buffer-alist's docstring. For the moment I find it quite obscure. > The label is needed since `bs-cycle-next' can pop > up an arbitrary buffer no regexp or name could selectively match. Yes, that at least I understand. And I'm sure once I grok the rest it will help simplifying my .emacs (for example, I will not need to strongly dedicate *buffer-selection*). Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 14:22 ` Juanma Barranquero @ 2011-06-27 20:11 ` Juanma Barranquero 0 siblings, 0 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-27 20:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 This code, which is mostly Martin's, fixes case 2. The user can override the "signal error" behavior by customizing display-buffer-alist or adding (push '(((label . bs-cycle-next) (label . bs-cycle-previous)) reuse-window (reuse-window same nil nil) (reuse-window-dedicated . t) (override . t)) display-buffer-alist) to their .emacs. OK to install? J === modified file 'lisp/bs.el' --- lisp/bs.el 2011-06-27 01:52:37 +0000 +++ lisp/bs.el 2011-06-27 19:59:41 +0000 @@ -1190,6 +1190,15 @@ (defvar bs--cycle-list nil "Current buffer list used for cycling.") +(defun bs--reuse-window-unless-dedicated (buffer &rest _args) + "Display BUFFER in the selected window. +If the selected window is dedicated, signal an error instead. +This function is intended to be called from `display-buffer'. +To override it, see `display-buffer-alist'." + (if (and (window-dedicated-p) (not (eq (window-buffer) buffer))) + (error "Selected window is dedicated to its buffer") + (display-buffer-same-window buffer))) + ;;;###autoload (defun bs-cycle-next () "Select next buffer defined by buffer cycling. @@ -1215,7 +1224,9 @@ ;; We don't want the frame iconified if the only window in the frame ;; happens to be dedicated. (bury-buffer (current-buffer)) - (switch-to-buffer next) + (display-buffer next + '((fun-with-args bs--reuse-window-unless-dedicated)) + 'bs-cycle-next) (setq bs--cycle-list (append (cdr cycle-list) (list (car cycle-list)))) (bs-message-without-log "Next buffers: %s" @@ -1244,7 +1255,9 @@ bs--cycle-list))) (prev-buffer (car tupel)) (cycle-list (cdr tupel))) - (switch-to-buffer prev-buffer) + (display-buffer prev-buffer + '((fun-with-args bs--reuse-window-unless-dedicated)) + 'bs-cycle-previous) (setq bs--cycle-list (append (last cycle-list) (reverse (cdr (reverse cycle-list))))) (bs-message-without-log "Previous buffers: %s" ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-27 1:53 ` Juanma Barranquero 2011-06-27 7:00 ` martin rudalics @ 2011-06-29 3:27 ` Stefan Monnier 2011-06-29 3:57 ` Juanma Barranquero ` (3 more replies) 1 sibling, 4 replies; 48+ messages in thread From: Stefan Monnier @ 2011-06-29 3:27 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> I'm not sure about the third (isn't it also fixed by passing a non-nil >> arg to bury-buffer?) > Well, yes, but that means "fixing" it everywhere; I mean: > emacs -Q > M-: (set-window-dedicated-p (selected-window) t) <RET> > M-x bury-buffer <RET> > and the frame is iconified. It shouldn't. As mentioned earlier, maybe the single-frame case is special, but I'd really first like to know how you get into such a state. For any other case, 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). > If switch-to-buffer is changed not to fallback on pop-to-buffer, why > shouldn't it be called from elisp? Because 99% of the calls are wrong (they just want to display a specific buffer and the author did not consider what should happen if called in a minibuffer-only frame or in a dedicated window). > In the case of bs-cycle-next: > (unless (window-dedicated-p (selected-window)) > ;; We don't want the frame iconified if the only window in the frame > ;; happens to be dedicated > (bury-buffer (current-buffer))) > (switch-to-buffer next) > the current switch-to-buffer causes the unwanted-splitting behavior. > Changing it to pop-to-buffer-same-window, as its docstring suggests, > would still cause the same problem. Yes, bs-cycle-next would be one of the very rare cases where calling switch-to-buffer is the right thing to do. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 3:27 ` Stefan Monnier @ 2011-06-29 3:57 ` Juanma Barranquero 2011-06-30 17:02 ` Stefan Monnier 2011-06-29 7:11 ` martin rudalics ` (2 subsequent siblings) 3 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-29 3:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > As mentioned earlier, maybe the single-frame case is special, but I'd > really first like to know how you get into such a state. As I explained, I have strongly-dedicated windows, and every now and then I end doing C-x 1 inside one of them. As it isn't usually what I wanted, I immediately do <f10> (which I have bound to bs-cycle-next). But, leaving aside my own use case, yeah, for the single frame use case, iconifying it is hardly going to be useful for anyone, I think. > For any other > case, 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). I don't even agree with your example, because I certainly wouldn't want my frames iconified (and, in any case, I'd use M-x iconify-frame <RET> for that). But explicit interactive calls of bury-buffer are not what I complain about; I don't mind these, because I just don't ever use them. My problem happens when bury-buffer is called from some elisp code that does a poor job of reading my mind: no, mr. program, I don't really want my frames iconified, thank you very much. bs-cycle-next is just the most prominent example of that bad behavior, because I use it a lot. So, I don't mind which is the default, as long as there's a way to customize it (with Martin's new window machinery, not redefining functions) to my tastes. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 3:57 ` Juanma Barranquero @ 2011-06-30 17:02 ` Stefan Monnier 2011-06-30 18:50 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2011-06-30 17:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 >> As mentioned earlier, maybe the single-frame case is special, but I'd >> really first like to know how you get into such a state. > As I explained, I have strongly-dedicated windows, and every now and > then I end doing C-x 1 inside one of them. As it isn't usually what I Where do these strongly dedicated windows come from? >> For any other case, 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). > <RET> for that). But explicit interactive calls of bury-buffer are not > what I complain about; I don't mind these, because I just don't ever > use them. Good. > My problem happens when bury-buffer is called from some > elisp code that does a poor job of reading my mind: no, mr. program, I > don't really want my frames iconified, thank you very much. Please report these cases. I suspect that in most cases the problem is not bury-buffer's behavior but that the command should not call bury-buffer (or not with a nil arg). > bs-cycle-next is just the most prominent example of that bad behavior, > because I use it a lot. That's indeed a case where (bury-buffer nil) was the wrong thing to do. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-30 17:02 ` Stefan Monnier @ 2011-06-30 18:50 ` Juanma Barranquero 2011-07-01 12:07 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2011-06-30 18:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Thu, Jun 30, 2011 at 19:02, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Where do these strongly dedicated windows come from? I set them in hooks; for example I do it with *buffer-selection* because I never want to switch to another buffer in the window that I use for temporary buffers. I think some of my uses can be simplified with Martin's changes, and indeed I will be doing a careful inspection of my .emacs looking for things to remove... > Please report these cases. Will do. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-30 18:50 ` Juanma Barranquero @ 2011-07-01 12:07 ` Juanma Barranquero 0 siblings, 0 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-07-01 12:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911-done On Thu, Jun 30, 2011 at 20:50, Juanma Barranquero <lekktu@gmail.com> wrote: Both complains about bs-cycle-next have been solved, and any bury-buffer issue should be reported separately, so I'm closing this bug. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 3:27 ` Stefan Monnier 2011-06-29 3:57 ` 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 3 siblings, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-29 7:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, 8911 > Because 99% of the calls are wrong (they just want to display > a specific buffer and the author did not consider what should happen if > called in a minibuffer-only frame or in a dedicated window). Why aren't minibuffer-only frame windows automatically dedicated? martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 7:11 ` martin rudalics @ 2011-06-30 17:06 ` Stefan Monnier 0 siblings, 0 replies; 48+ messages in thread From: Stefan Monnier @ 2011-06-30 17:06 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 8911 >> Because 99% of the calls are wrong (they just want to display >> a specific buffer and the author did not consider what should happen if >> called in a minibuffer-only frame or in a dedicated window). > Why aren't minibuffer-only frame windows automatically dedicated? Maybe just because they predate the notion of dedicatedness? Or because a minibuffer-only frame will show different buffers at different times (think of echo-area buffers, recursive minibuffers, ...), so "dedicated" isn't quite right. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 3:27 ` Stefan Monnier 2011-06-29 3:57 ` Juanma Barranquero 2011-06-29 7:11 ` martin rudalics @ 2011-06-29 11:36 ` Juanma Barranquero 2011-06-29 15:36 ` Drew Adams 3 siblings, 0 replies; 48+ messages in thread From: Juanma Barranquero @ 2011-06-29 11:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8911 On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Yes, bs-cycle-next would be one of the very rare cases where calling > switch-to-buffer is the right thing to do. Which is exactly what the patch I sent for case 2 (bs-cycle-next vs. dedicated windows) does. It's OK to install, or do you object to it? Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 3:27 ` Stefan Monnier ` (2 preceding siblings ...) 2011-06-29 11:36 ` Juanma Barranquero @ 2011-06-29 15:36 ` Drew Adams 2011-06-29 18:21 ` Drew Adams 3 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2011-06-29 15:36 UTC (permalink / raw) To: 'Stefan Monnier', 'Juanma Barranquero'; +Cc: 8911 > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 15:36 ` Drew Adams @ 2011-06-29 18:21 ` Drew Adams 2011-06-30 7:00 ` martin rudalics 0 siblings, 1 reply; 48+ messages in thread From: Drew Adams @ 2011-06-29 18:21 UTC (permalink / raw) To: 'Stefan Monnier', 'Juanma Barranquero'; +Cc: 8911 > 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. Let me also be clear that it is not about hook vs option. It would be fine with me if we had a user option for this instead of a hook, as long as it let you do just as much. E.g., a function to be invoked after the buffer order is changed. Function `ignore' would take care of the do-nothing case. The function would need to accept the buffer as its (first) argument. What I object to is Stefan's proposal of an option that allows only a choice between deleting the frame and iconifying it. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-29 18:21 ` Drew Adams @ 2011-06-30 7:00 ` martin rudalics 2011-06-30 15:31 ` Drew Adams 0 siblings, 1 reply; 48+ messages in thread From: martin rudalics @ 2011-06-30 7:00 UTC (permalink / raw) To: Drew Adams; +Cc: 'Juanma Barranquero', 8911 > Let me also be clear that it is not about hook vs option. It would be fine with > me if we had a user option for this instead of a hook, as long as it let you do > just as much. Since I hardly ever bury a buffer please tell me when and how you want to set up things and what precisely you want that option to do. We now have an option called `frame-auto-delete' which might be expanded to do something in this sense. > E.g., a function to be invoked after the buffer order is changed. `buffer-list-update-hook' is run when the "buffer order" changes. Note that there were "f + 1" buffer orders in Emacs 23 where "f" is the number of live frames and there are "f + w + 1" buffer orders in Emacs 24 where "w" is the number of live windows. > Function > `ignore' would take care of the do-nothing case. The function would need to > accept the buffer as its (first) argument. `buffer-list-update-hook' doesn't have a buffer as argument. We could change that. But this would not necessarily tell you enough about the frame that should be deleted or iconified. > What I object to is Stefan's proposal of an option that allows only a choice > between deleting the frame and iconifying it. martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-30 7:00 ` martin rudalics @ 2011-06-30 15:31 ` Drew Adams 0 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2011-06-30 15:31 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 'Juanma Barranquero', 8911 > > Let me also be clear that it is not about hook vs option. > > It would be fine with me if we had a user option for this > > instead of a hook, as long as it let you do just as much. > > Since I hardly ever bury a buffer please tell me when and how you want > to set up things and what precisely you want that option to > do. I hardly ever (never?) bury a buffer explicitly either. But as Juanma pointed out, we all use (vanilla) Lisp code that calls `bury-buffer'. Anyway, I don't have a precise idea wrt such an option. The general idea is to give users some (easy) way to specify a particular behavior to invoke after `bury-buffer' does its thing of changing the buffer order. IOW, that extra behavior would be invoked/initiated by `bury-buffer'. This is not (for me) about any old change in the buffer order. It is only about complementing the buffer order-changing behavior of `bury-buffer' by adding some user-specified (display) behavior. > We now have an option called `frame-auto-delete' which > might be expanded to do something in this sense. I don't know anything about that. This is not fundamentally about frame deletion. Deleting the frame in this situation would be only one possible user preference. We should not focus on it in particular, I think. > > E.g., a function to be invoked after the buffer order is changed. > > `buffer-list-update-hook' is run when the "buffer order" > changes. Note that there were "f + 1" buffer orders in > Emacs 23 where "f" is the number of live frames and there > are "f + w + 1" buffer orders in Emacs 24 where "w" is > the number of live windows. Again, I'm no expert on this, in any Emacs version. This is about `bury-buffer' (only), and therefore about its particular reordering of the buffer list. After it reorders the list to bury the buffer, a given user (e.g. Stefan, Drew) might want `bury-buffer' to do something about the window or frame that displays that buried buffer. That's the idea - let users specify that display behavior. But I suppose that any behavior whatever could be handled here, not necessarily something to do with displaying that particular buffer window/frame. Put differently, specifying what to do in addition to changing the buffer order could involve other things besides (in addition to or instead of) display. > > Function `ignore' would take care of the do-nothing case. > > The function would need to accept the buffer as its (first) > > argument. > > `buffer-list-update-hook' doesn't have a buffer as argument. We could > change that. But this would not necessarily tell you enough about the > frame that should be deleted or iconified. I don't think (without really knowing anything about that hook) that that hook would be appropriate here. This is only about `bury-buffer' and _its_ particular reordering of the buffer list to bury the buffer. But you're no doubt right that knowing only the buffer would not be enough. Probably the function (option value or new-hook entry) should take the buffer's window as argument also. `bury-buffer' knows what that window is. The idea is to let `bury-buffer' do something about the buffer's window/frame, if the user wants that. That's all. I'd guess that knowing the buffer and the window would be enough. The frame can be gotten from the window. So pretty much anything the user would like to do in this context should be possible by specifying a function that accepts the buffer and window as args. Unless I'm missing something. Ideally, the user should be able to specify a function that accepts those two args and does anything it wants. It could test other things in the current context, besides that buffer and window, and do something appropriate wrt the buffer's display. It could do something different depending on whether this is a special-display situation, or depending on what the buffer name is, or... I'm not trying to specify the exact implementation. No doubt both of you have good ideas about that. My only point is that we should try to: 1. Decouple burying the buffer (changing the buffer order) from doing something about the buffer's display. 2. Let users optionally specify something to do wrt the buffer's display. 3. Make sure that #2 is open-ended, not limited to just choosing between deleting the buffer's frame and iconifying it. A question is whether this is all about just the dedicated-window case or not. We've kind of been talking as if it is only about that case. And that sounds right to me. But we might also want to think about whether such a feature (user specification of what to do about display, after reordering the buffer list) would/should/could also be applicable to other, non dedicated-window, cases for `bury-buffer'. Dunno. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 16:28 ` Juanma Barranquero 2011-06-21 17:15 ` Drew Adams @ 2011-06-22 2:07 ` Stefan Monnier 1 sibling, 0 replies; 48+ messages in thread From: Stefan Monnier @ 2011-06-22 2:07 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 8911 > Please note a difference between your use of Emacs and mine: I *never* > use multiple frames. So if I happen to have a dedicated window and I > accidentaly try to bury the buffer, iconifying my only frame is never, > ever going to be useful. It will *always* be followed by de-iconifying > it and then fixing the problem. Iconifying should only happen if the window is dedicated *and* it's the only window in the frame. How do you ever get into such a state in your single-frame use? > Of course, it's not often that I have a single, dedicated window in > the frame. But I use dedicated windows for some things (like the > output of bs-show), and I sometimes do C-x 1 while on one of these > buffers. Ah... I guess we could work around the problem by deciding that we should additionally check that there's some other frame displayed before iconifying a frame. Not sure what a real fix would look like. Stefan ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 16:22 ` Stefan Monnier 2011-06-21 16:28 ` Juanma Barranquero @ 2011-06-21 16:36 ` martin rudalics 2011-06-21 17:07 ` Drew Adams 2 siblings, 0 replies; 48+ messages in thread From: martin rudalics @ 2011-06-21 16:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, 8911 >> The trouble was that, when called on a dedicated window, it iconified >> the frame. > > I don't follow: why do you think it's a trouble? To me it's exactly > what I want. Is it that you prefer it deletes the frame rather than > iconify it? No. But I recall that people disliked iconified frames. > Not sure if it's needed. Calling bury-buffer with a non-nil arg should > be sufficient. Indeed, that's the best solution. martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#8911: bs-cycle-next deletes window in some cases. 2011-06-21 16:22 ` Stefan Monnier 2011-06-21 16:28 ` Juanma Barranquero 2011-06-21 16:36 ` martin rudalics @ 2011-06-21 17:07 ` Drew Adams 2 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2011-06-21 17:07 UTC (permalink / raw) To: 'Stefan Monnier', 'Juanma Barranquero'; +Cc: 8911 Caveat: I have not really been following this thread closely. > > The trouble was that, when called on a dedicated window, it > > iconified the frame. > > I don't follow: why do you think it's a trouble? To me it's exactly > what I want. Is it that you prefer it deletes the frame rather than > iconify it? FWIW, iconifying is not what I would prefer. `bury-buffer' is primarily about buffer order. It's about getting the buffer out of the way for `other-buffer'. Only secondarily is it at all about display (almost as an afterthought): "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. Iconifying can be annoying, depending on your OS. I really don't see it as appropriate for `bury-buffer'. If code wants to iconify the frame it can always do so explicitly. Likewise for frame deletion, of course. 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. Wrt `bs-cycle-next': I'm no expert on that (I don't use it), but wouldn't it make sense for this kind of thing to _not_ affect the order of the default buffer list, but rather to cycle its own copy/version of that list? In that case, `bs' could decide how to handle buffers in dedicated windows for its own purposes (cycling display), without altering the standard buffer order. This would decouple `bs' cycling from `other-buffer' - would that be a good/bad thing? Dunno. E.g., A priori, I see no reason why a buffer in a dedicated window should be removed from the buffer list (by `bs-cycle-next' etc.). The requirement seems to be only for `bs-cycle-next' to ignore that buffer or skip over it or something. But why should that action alter the standard buffer list? Again, I haven't followed this, and I know very little about `bs' etc. If what I say makes no sense, please ignore it. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2011-07-01 12:07 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.