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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 1806 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: bug#1806: dired-pop-to-buffer in wrong place
Date: Fri, 16 Oct 2009 09:15:41 -0400

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

Agreed.  As discussed in some earlier thread, I think the
`not-this-window' argument of diaplay-buffer (aka `other-window' for
pop-to-buffer) should be extended to allow a description of where the
buffer should preferentially go (i.e. the application's preference),
where one such preference could be `nearby' or `near-minibuffer' which
would basically mean to follow the rules of dired-pop-to-buffer.

These preferences would be subject to overruling via special-display-regexps.

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

Agreed.  If side-by-side splitting is desirable, it is the user's
responsibility to do C-x 3 before invoking calendar.


        Stefan

Previous Next

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