bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> So what I really need to know is how you (1) expect this to work
>> ideally, and (2) how to proceed when (1) fails.

> I think the current behavior of `dired-pop-to-buffer' is ideal in this
> regard.  We just have to generalize it and move its logic to window.el
> to allow other applications to use the same logic.

Agreed.  As discussed in some earlier thread, I think the
`not-this-window' argument of diaplay-buffer (aka `other-window' for
pop-to-buffer) should be extended to allow a description of where the
buffer should preferentially go (i.e. the application's preference),
where one such preference could be `nearby' or `near-minibuffer' which
would basically mean to follow the rules of dired-pop-to-buffer.

These preferences would be subject to overruling via special-display-regexps.

>> As for the *Calendar* window I thought that Glenn wanted to do some
>> side-by-side splitting first because of the wasted space in a frame-wide
>> *Calendar* window.  So your proposal wouldn't help in this case.

> We should not decide on behalf of the user what window space is wasted
> and fill it with some arbitrary buffers.

Agreed.  If side-by-side splitting is desirable, it is the user's
responsibility to do C-x 3 before invoking calendar.


        Stefan