GNU bug report logs - #1806
dired-pop-to-buffer in wrong place

Previous Next

Full log

Message #540 received at 1806 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 1806 <at> debbugs.gnu.org
Subject: Re: bug#1806: dired-pop-to-buffer in wrong place
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.