bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/17 martin rudalics <rudalics@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@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