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


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

From: Carsten Dominik <dominik <at> science.uva.nl>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 1806 <at> debbugs.gnu.org,
        Carsten Dominik <dominik <at> science.uva.nl>
Subject: Re: bug#1806: dired-pop-to-buffer in wrong place
Date: Thu, 8 Jan 2009 12:52:04 +0100
[Message part 1 (text/plain, inline)]
On Jan 7, 2009, at 11:27 AM, martin rudalics wrote:

> > I can't image a situation when someone will want to display a narrow
> > window on a full-height side window.  At least I think currently  
> we should
> > restore the old behavior when these commands displayed a narrow  
> window
> > below the original window instead of a side window.
>
> I did this for `dired-pop-to-buffer'.
>
> > I think a general rule of thumb for finding all such cases should  
> be the
> > following: when there is a call to `fit-window-to-buffer' after  
> calling
> > `pop-to-buffer' then split windows vertically because otherwise
> > `fit-window-to-buffer' makes no sense since it adjusts the window  
> height
> > and can't do this on a full-height horizontally split window.
>
> Good suggestion. I found the following candidates:
>
> `Electric-pop-up-window', `ibuffer-confirm-operation-on',
> `disabled-command-function', `proced-send-signal',
> `fancy-startup-screen', `display-time-world', `widget-choose'.
>
> Can someone comment on these?  We might also have to consider windows
> affected by `temp-buffer-resize-mode'.  I'll leave it to Carsten to
> figure out what's best for `org-mode'.

Hi Martin,

org-mode already protects itself against this possibility, I think:
Here is my code:

(defun org-fit-window-to-buffer (&optional window max-height min-height
					   shrink-only)
  "Fit WINDOW to the buffer, but only if it is not a side-by-side  
window.
WINDOW defaults to the selected window.  MAX-HEIGHT and MIN-HEIGHT are
passed through to `fit-window-to-buffer'.  If SHRINK-ONLY is set, call
`shrink-window-if-larger-than-buffer' instead, the hight limit are
ignored in this case."
  (cond ((> (frame-width) (window-width window))
	 ;; do nothing if another window would suffer
	 )
	((and (fboundp 'fit-window-to-buffer) (not shrink-only))
	 (fit-window-to-buffer window max-height min-height))
	((fboundp 'shrink-window-if-larger-than-buffer)
	 (shrink-window-if-larger-than-buffer window)))
  (or window (selected-window)))


If the current window is not the full frame width, I do not adjust its  
size because it would shink other windows along with it.

- Carsten



>
>
> As for `calendar' I share Stefan's POV ...
>
> martin

[Message part 2 (text/html, inline)]

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.