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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> jurta.org>

Date: Tue, 6 Jan 2009 15:40:04 UTC

Severity: normal

Done: Juri Linkov <juri <at> jurta.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1806 <at> debbugs.gnu.org
Subject: bug#1806: dired-pop-to-buffer in wrong place
Date: Fri, 16 Oct 2009 12:38:43 +0300
>> 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/



This bug report was last modified 12 years and 236 days ago.

Previous Next


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