GNU bug report logs -
#7368
display-buffer may not respect pop-up-frames value
Previous Next
Full log
Message #52 received at 7368 <at> debbugs.gnu.org (full text, mbox):
2010/11/17 martin rudalics <rudalics <at> gmx.at>:
>> Do you agree with points 1-6?
>
> If you rewrote them correctly, maybe.
Ok, let's try again ;-) I completely messed up set-window-buffer and
switch-to-buffer, sorry.
1) In principle, set-window-buffer may fail.
2) set-window-buffer doesn't fail in
(let ((foo (get-buffer-create "foo"))
(bar (get-buffer-create "bar"))
(baz (get-buffer-create "baz")))
(switch-to-buffer foo)
(delete-other-windows)
(let ((bar-window (display-buffer bar t)))
(set-window-dedicated-p bar-window 'soft)
(set-window-buffer bar-window baz)))
3) display-buffer uses set-window-buffer as a subroutine.
4) display-buffer checks some conditions before calling
set-window-buffer, because the latter may fail.
5) display-buffer fails in
(let ((foo (get-buffer-create "foo"))
(bar (get-buffer-create "bar"))
(baz (get-buffer-create "baz")))
(switch-to-buffer foo)
(delete-other-windows)
(let ((bar-window (display-buffer bar t)))
(set-window-dedicated-p bar-window 'soft))
(display-buffer baz t))
6) This is because checks in display-buffer before calling
set-window-buffer and inside set-window-buffer are different.
7) I believe this is not logical and should be fixed.
8) I think there is an easy way to fix it by checking for dedicated =
t instead of dedicated != nil inside get-lru-window and
get-largest-window (by the way, is there any chance those are
implemented in Lisp?).
2010/11/17 martin rudalics <rudalics <at> gmx.at>:
> If the window is dedicated for the sole purpose to make it disappear
> when it's no more need I tend to agree. There are better solutions.
Please tell which.
> But if an application is allowed to display another buffer _while the
> completions window is shown_ it would be a bad idea to use the
> completions window.
The minibuffer.el 's completion mechanism does not impose any
restrictions on what you can do while *Completions* is visible. That's
slightly off-topic, but I think it allows more user freedom and
clearer code.
> The _only_ purpose of weakly dedicated windows is to not allow
> `display-buffer' to use them.
I disagree. As a matter of fact, weakly dedicated windows possess
another property: they are deleted when their buffer is killed.
As a matter of personal opinion, "not allow `display-buffer' to use
them, but allow `set-window-buffer' to use them" is very hard concept
to understand. Especially given that `display-buffer' uses
`set-window-buffer' inside ;-) Even harder to understand is the
distinction between weakly and truly dedication.
I think that the following is much easier to grasp (although that's
not the primary goal):
1) Weakly dedicated: auto-closes when it's buffer is closed.
2) Truly dedicated: cannot display another buffer, auto-closes when
it's buffer is closed.
> What else would they be good for after
> your "fix"? And what would you do if someone made completion windows
> strongly dedicated to their buffer?
I do not know. But thinking a bit, completion windows would be
"persistent" (would not disappear until you kill it explicitly). I can
imagine it might be not useless.
However I personally wouldn't make them strongly dedicated and
wouldn't advice to do so.
> IIUC the sequence of events is
>
> (1) the application issues a call for getting the name of a buffer,
>
> (2) the user enters the name with the assistance of the completion
> routines,
>
> (3) the completion routines return the name,
>
> (4) the caller displays the buffer with that name.
>
No. The command showing *Completions* and command calling
display-buffer are totally unrelated. See the first message.
Best wishes,
Andrey Paramonov
This bug report was last modified 10 years and 237 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.