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

[martin rudalics]

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

`dired-pop-to-buffer' explicitly specifies that it wants to split the
selected window.  Your defcustom does not specifiy _which_ window to
split.

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

For that purpose we would have to specify (1) which window should be
split preferably and (2) how to split that window.

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

I agree.  We're in a lose-lose situation here.  Popping up a separate
frame would be probably better here.

martin