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

From: martin rudalics <[email-masked]>
Date: Fri, 16 Oct 2009 14:04:56 +0200

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