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

[Juri Linkov]

>> I think some applications (where such exceptions make sense) by default
>> should ignore split-width-threshold and let `pop-to-buffer' to split
>> vertically.  And window.el should provide a simple user option to define
>> these exceptions that will specify how to split windows based on the
>> buffer names similar to `same-window-buffer-names'.  For instance,
>>
>> (defcustom split-window-buffer-names
>>            '(("*Calendar*" . vertically)
>>              (" *Marked Files*" . vertically))
>
> Is there a good reason why these applications should endure the present
> heuristics of `pop-to-buffer' in the first place?  Shouldn't *Marked
> Files* appear beneath the window where the marking took place?  That
> latter window might not be the largest one and is almost certainly not
> the LRU one, so the *Marked Files* window might not show up in a very
> suitable place anyway.  I suppose the *Marked Files* window should be
> obtained by first trying to deterministically split the window where the
> marking took place and only when splitting fails have `pop-to-buffer'
> find a suitable window.

That's what I actually meant and what `dired-pop-to-buffer' already does.

> 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.

> 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.

-- 
Juri Linkov
http://www.jurta.org/emacs/