bug#7368: display-buffer a softly dedicated window

["Андрей Парамонов" <cmr.pent@gmail.com>]

2010/11/17 Stefan Monnier <monnier@iro.umontreal.ca>:
>> 1) A "softly dedicated" window is a window tied to a certain buffer,
>> and when that buffer is destroyed the window is destroyed too.
>
> I think in general that would not be right (e.g. for my use of
> soft-dedicated windows).

I'm curious what is your use-case. Would truly-dedicated windows fit it?

> But I agree that display-buffer should
> probably override the soft-dedication in the case where it would
> otherwise have to create a new frame and the user has pop-up-frames set
> to nil.
>

I bevieve it's reasonable to override soft-dedication unconditionally.
The checks for dedicated != nil seem to be needed only because
switch-to-buffer would fail on a "truly dedicated" buffer. However,
switch-to-buffer would never fail on a "softly dedicated" buffer, only
on a "truly dedicated" one, so it seems logical to rather check for
dedicated = t.

I strongly believe display-buffer and switch-to-buffer should do the
same thing in the following minimal example:

(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)
   (select-window bar-window)
   (switch-to-buffer baz)))

(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))

For that to work, only a small patch for get-lru-window and
get-largest-window is needed. However I understand that although
logical, this tiny change might break something. Should I relabel the
bug accordingly, or create a new one?

Best wishes,
Andrey Paramonov