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

Previous Next

Full log

Message #60 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: Wed, 07 Jan 2009 16:34:10 +0100

> However, when windows are already split horizontally,
> it still doesn't work like it always worked by displaying
> a small window below.  As you can see in the code removed
> from `dired-pop-to-buffer' it used to call `split-window'
> explicitly:
>
> (setq w2 (split-window window
> 		  (max window-min-height
> 		       (- (window-height window)
> 			  (1+ (max window-min-height target-lines))))))

Usually this worked correctly due to the fact that directory buffers
were sufficiently high.  But for `pop-up-frames' non-nil addicts this
was not necessarily the right behavior.

Anyway, I suppose you mean something like

(defun dired-pop-to-buffer (buf)
  (let* ((split-height-threshold 8)
	 split-width-threshold
	 (buffer (get-buffer-create buf))
	 (window (window--try-to-split-window (selected-window))))
    (if window
	(progn
	  (select-window window)
	  (set-window-buffer window buffer))
      (pop-to-buffer buffer))
    (when dired-shrink-to-fit
      (fit-window-to-buffer nil nil 1))))

> Please see the code in calendar.el that creates such standard layout
> for non-wide-screen configurations (i.e. when there is no right window).
> I think we should keep exactly the same logic for wide-screen configurations,
> i.e. treating the creation of such small low windows as if there is no
> existing side window.

Would the above code handle that?

martin

Previous Next

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