bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Christoph Scholtes]

emacs -Q
C-x d <ret>
C-x 2
select at least to files for deletion with `d'
press x

The top window now shows the *Deletions* buffer at the bottom, but the
size of the top dired buffer shrunk by about a third.

This only happens when the frame is split with C-x 2 to show two windows.



In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601)
 of 2011-10-24 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.6) --no-opt --cflags -I"D:/devel/emacs/libs/libXpm-3.5.8/include" -I"D:/devel/emacs/libs/libXpm-3.5.8/src" -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include" -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" -I"D:/devel/emacs/libs/giflib-4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" -I"D:/devel/emacs/libs/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags -L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  my-keys-minor-mode: t
  erc-autojoin-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-pcomplete-mode: t
  erc-stamp-mode: t
  global-auto-complete-mode: t
  gnus-undo-mode: t
  desktop-save-mode: t
  ido-everywhere: t
  yas/global-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> M-d M-d M-d 
M-d M-d <left> <backspace> SPC a n d M-q <down> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <backspace> ? <right> 
M-d C-d <right> <right> <right> <right> <right> <right> 
t h e n SPC M-q <down> <down> <backspace> . <up> <up> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<up> <up> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <M-backspace> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> C-k <down> <down> <down> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <down> <down> . . <backspace> <backspace> <down> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <left> h <down> <down> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <left> 
<left> <left> , SPC b u t C-c C-c g <return> C-n C-n 
C-n C-n C-n C-n C-n C-n <return> C-p C-p C-p C-p C-p 
C-p C-p C-p <return> q g <down-mouse-1> <mouse-1> M-x 
r e p o r t - e <tab> <return>

Recent messages:
Checking new news...
nnimap read 0k
nnimap read 26k
Reading active file from archive via nnfolder...done
Checking new news...done
nnimap read 0k
Checking new news...
nnimap read 0k
Reading active file from archive via nnfolder...done
Checking new news...done

Load-path shadows:
c:/Users/Christoph/AppData/Roaming/.emacs.d/plugins/python hides d:/devel/emacs/emacs-bzr/trunk_jenkins/lisp/progmodes/python

Features:
(shadow emacsbug vc-bzr multi-isearch etags flow-fill vc-hg mailalias
smtpmail sendmail newcomment qp sort mule-util ansi-color gnus-cite
mail-extr gnus-async gnus-bcklg gnus-ml gnus-topic nndraft nnmh nnfolder
utf-7 gnutls network-stream auth-source eieio starttls nnimap parse-time
tls utf7 netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime
password-cache dig mailcap nntp gnus-cache paredit org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp
ob-exp org-exp-blocks org-agenda org-info org-gnus org-docview
org-bibtex bibtex org-bbdb org byte-opt warnings bytecomp byte-compile
cconv ob-emacs-lisp ob-tangle ob-ref ob-lob ob-table org-footnote
org-src ob-comint ob-keys ob ob-eval org-pcomplete org-list org-faces
org-compat org-entities org-macs noutline outline cal-menu calendar
cal-loaddefs my-zenburn-theme erc-join erc-track erc-match erc-pcomplete
pcomplete erc-stamp erc-goodies erc erc-backend erc-compat thingatpt
windmove auto-complete-config auto-complete popup find-func ispell
bookmark+ bookmark+-key dired-x dired bookmark+-1 nnir gnus-sum macroexp
nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec
gnus-int gnus-range message format-spec rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader
gnus-util mail-utils mm-util mail-prsvr wid-edit bookmark+-bmu help-mode
view bookmark+-lit pp+ bookmark+-mac bookmark pp midnight desktop
ibuffer uniquify autopair google-c-style cc-styles cc-align cc-engine
cc-vars cc-defs grep-o-matic grep compile comint regexp-opt ring
browse-kill-ring+ browse-kill-ring second-sel ido yasnippet
dropdown-list derived easy-mmode edmacro kmacro easymenu assoc cl
org-install server advice help-fns advice-preload debbugs-autoloads
package tabulated-list autorevert time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer button faces cus-face files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
multi-tty emacs)

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juanma Barranquero]

> emacs -Q

Try with

  emacs -Q --eval "(setq window-nest t)"

    Juanma

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Christoph Scholtes]

Juanma Barranquero <lekktu@gmail.com> writes:

> Try with
>
>   emacs -Q --eval "(setq window-nest t)"

Thanks Juanma, this fixes the problem. I am not sure I understand what
other implications this has, though. Was this meant to be a test or a
permanent solution?

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juanma Barranquero]

On Wed, Oct 26, 2011 at 04:50, Christoph Scholtes
<cschol2112@googlemail.com> wrote:

> Thanks Juanma, this fixes the problem. I am not sure I understand what
> other implications this has, though.

You'll have to ask Martin for that.

> Was this meant to be a test or a permanent solution?

Is what I have in my .emacs.

    Juanma

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 >> Thanks Juanma, this fixes the problem. I am not sure I understand what
 >> other implications this has, though.
 >
 > You'll have to ask Martin for that.

The Elisp manual should cover `window-nest' in some detail.  Please have
a look.

BTW this bug has been first described by Juri in Message#65 of Bug#1806.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Eli Zaretskii]

> Date: Wed, 26 Oct 2011 11:22:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Christoph Scholtes <cschol2112@googlemail.com>, 9873@debbugs.gnu.org
> 
>  >> Thanks Juanma, this fixes the problem. I am not sure I understand what
>  >> other implications this has, though.

Lucky you.  I didn't understand a thing about it.

> The Elisp manual should cover `window-nest' in some detail.  Please have
> a look.

IMNSHO, the doc string needs "Some Work"®, as right now it's
impenetrable for mere mortals (this being is a user option).  Users
aren't, and shouldn't be, aware that windows are arranged in a tree.
Without a very good understanding of that, talking about "a new parent
window" and "binary tree of windows" misses the target by a very large
measure.

Besides, user options should be first and foremost be described in the
user manual, not in the ELisp manual.

After reading what's written in the ELisp manual (and digressing to
"Windows and Frames" for a while, to understand what the heck it is
talking about when it says "parent window"), I do understand what the
variable does in terms of the window tree, but still cannot tell I
understand its effects in practice, beyond the specific example of
splitting and unsplitting windows that is described there in detail.
Is this the only user-visible effect of this variable?  If so, why not
name it something that is related to resizing or splitting, and why
not say that in the doc string, instead of describing the window tree
and the "parent window" which a user will never see and does not care
about in the first place?  Since when do we explain user-level
features in terms of abstract data types and structures that are all
but invisible to users??

I'm sorry for being so blunt, but it's the first time I've read in an
Emacs manual a whole section, which does a very good job at describing
what it sets out to describe, but is completely useless for me as a
guide for understanding the practical implications of a certain user
option.

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 >> The Elisp manual should cover `window-nest' in some detail.  Please have
 >> a look.
 >
 > IMNSHO, the doc string needs "Some Work"®, as right now it's
 > impenetrable for mere mortals (this being is a user option).  Users
 > aren't, and shouldn't be, aware that windows are arranged in a tree.
 > Without a very good understanding of that, talking about "a new parent
 > window" and "binary tree of windows" misses the target by a very large
 > measure.

Describing what `window-nest' does without referring to the window tree
is virtually impossible (aat least for me).

 > Besides, user options should be first and foremost be described in the
 > user manual, not in the ELisp manual.

Agreed.  But since I apparently failed to convey the semantics of this
variable in the Elisp manual, someone else will have to take care of
writing such a description ;-)

 > After reading what's written in the ELisp manual (and digressing to
 > "Windows and Frames" for a while, to understand what the heck it is
 > talking about when it says "parent window"), I do understand what the
 > variable does in terms of the window tree, but still cannot tell I
 > understand its effects in practice, beyond the specific example of
 > splitting and unsplitting windows that is described there in detail.
 > Is this the only user-visible effect of this variable?

No.  Suppose a window W is a vertical combination of two windows W1 and
W2 and W2 is a vertical combination of two windows W3 and W4.  In this
case resizing W will equally affect W1 and W2 and consequently W1 more
than W3 or W4.  This is different from the case where W is a vertical
combination of three live windows W1, W3 and W4.

 > If so, why not
 > name it something that is related to resizing or splitting, and why
 > not say that in the doc string, instead of describing the window tree
 > and the "parent window" which a user will never see and does not care
 > about in the first place?  Since when do we explain user-level
 > features in terms of abstract data types and structures that are all
 > but invisible to users??

This is the Elisp manual and I have been trying to explain all related
terms in the section "Windows and Frames".  If there's something
missing, including cross references to that section, you're welcome to
fix that.

 > I'm sorry for being so blunt, but it's the first time I've read in an
 > Emacs manual a whole section, which does a very good job at describing
 > what it sets out to describe, but is completely useless for me as a
 > guide for understanding the practical implications of a certain user
 > option.

One practical implication of not having that option is evident from the
example.  If it has further implications, then that's something we will
find out as soon as people have started to customize it.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Eli Zaretskii]

> Date: Wed, 26 Oct 2011 16:22:59 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, cschol2112@googlemail.com, 9873@debbugs.gnu.org
> 
> Describing what `window-nest' does without referring to the window tree
> is virtually impossible (aat least for me).

Well, how about explaining why this variable was introduced, for
starters?  What problem(s) did its introduction try to solve?

>  > Is [splitting and unsplitting windows] the only user-visible
>  > effect of this variable?
> 
> No.  Suppose a window W is a vertical combination of two windows W1 and
> W2 and W2 is a vertical combination of two windows W3 and W4.  In this
> case resizing W will equally affect W1 and W2 and consequently W1 more
> than W3 or W4.  This is different from the case where W is a vertical
> combination of three live windows W1, W3 and W4.

Sorry, I don't get the drift.  What do you mean by "resizing W"? how
can one resize "a vertical combination" of 2 or 3 windows, which AFAIU
is just a node in the window tree, not a live window that is displayed
on a frame?  I mean, I can resize W1, W2, or W3, but how do I resize
their combination?

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Christoph Scholtes]

martin rudalics <rudalics@gmx.at> writes:

> The Elisp manual should cover `window-nest' in some detail.  Please have
> a look.
>
> BTW this bug has been first described by Juri in Message#65 of Bug#1806.

I see. Was there ever a conclusion reached? 

Ibuffer has the same issue, btw.

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 > Well, how about explaining why this variable was introduced, for
 > starters?  What problem(s) did its introduction try to solve?

Its introduction modifies the behavior of splitting, resizing and
deleting windows in the order described in the example in the manual.
Bug reports #1806 and #9873 confirm that the behavior of Emacs 23 in
this regard is problematic, at least

 > Sorry, I don't get the drift.  What do you mean by "resizing W"? how
 > can one resize "a vertical combination" of 2 or 3 windows, which AFAIU
 > is just a node in the window tree, not a live window that is displayed
 > on a frame?

You won't get the drift as long as you insist that an internal window is
"just a node in the window tree".

 > I mean, I can resize W1, W2, or W3, but how do I resize
 > their combination?

By resizing their parent window or a sibling of their parent window.  Or
by resizing the containing frame.  Or by resizing the minibuffer window.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 >> BTW this bug has been first described by Juri in Message#65 of Bug#1806.
 >
 > I see. Was there ever a conclusion reached?

No.

 > Ibuffer has the same issue, btw.

More will turn up.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Eli Zaretskii]

> Date: Thu, 27 Oct 2011 11:51:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, cschol2112@googlemail.com, 9873@debbugs.gnu.org
> 
>  > Well, how about explaining why this variable was introduced, for
>  > starters?  What problem(s) did its introduction try to solve?
> 
> Its introduction modifies the behavior of splitting, resizing and
> deleting windows in the order described in the example in the manual.

I understand that it affects resizing (by changing which other window
is resized as side effect of changing the size of the window we want
to resize), and deleting (by controlling which window will be given
the space released by the deleted one).  But what is modified in the
behavior of splitting?

>  > Sorry, I don't get the drift.  What do you mean by "resizing W"? how
>  > can one resize "a vertical combination" of 2 or 3 windows, which AFAIU
>  > is just a node in the window tree, not a live window that is displayed
>  > on a frame?
> 
> You won't get the drift as long as you insist that an internal window is
> "just a node in the window tree".

What I mean is that the user have no way of resizing the internal
windows, only the live windows, AFAIK.

A Lisp program can resize an internal window, but doing so is
precisely equivalent to resizing one of the live windows on the same
frame (again, AFAIK).

When you talk about resizing a live window, I understand exactly what
is meant.  If by "vertical combination" you mean the internal window
that is the parent of 2 or more live windows, I can understand that as
well, assuming that you are talking about a Lisp program.

If you mean anything else, please explain what I am missing.

>  > I mean, I can resize W1, W2, or W3, but how do I resize
>  > their combination?
> 
> By resizing their parent window or a sibling of their parent window.  Or
> by resizing the containing frame.  Or by resizing the minibuffer window.

Some of these are unavailable to users.  We were talking about a user
option.

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 >> Its introduction modifies the behavior of splitting, resizing and
 >> deleting windows in the order described in the example in the manual.
 >
 > I understand that it affects resizing (by changing which other window
 > is resized as side effect of changing the size of the window we want
 > to resize), and deleting (by controlling which window will be given
 > the space released by the deleted one).  But what is modified in the
 > behavior of splitting?

There's yet another new variable called `window-splits'.  That variable
allows to steal space from other windows when splitting, so you can
"split" windows which are otherwise too small.  Now if `window-nest' is
non-nil, `window-splits' has no effect.

 > What I mean is that the user have no way of resizing the internal
 > windows, only the live windows, AFAIK.
 >
 > A Lisp program can resize an internal window, but doing so is
 > precisely equivalent to resizing one of the live windows on the same
 > frame (again, AFAIK).

No.  Resizing an internal window with two child windows usually resizes
_both_ child windows proportionally (usually so, because edge dragging
behaves different from other forms of resizing).

 > When you talk about resizing a live window, I understand exactly what
 > is meant.

Then you know more than me.  Resizing a live window can resize all other
windows on the same frame.  Adjusting the edge of a live window can be
different from enlarging that window.  In addition, the nest and splits
status of the window affect the outcome as well.  All I know is that
when I resize a window in a certain way, I can live with the result, or
not.  In the latter case, I try to fix the behavior.  But I gave up
understanding what happens some time ago.

 > If by "vertical combination" you mean the internal window
 > that is the parent of 2 or more live windows, I can understand that as
 > well, assuming that you are talking about a Lisp program.

A vertical combination is slightly more than a parent window.  It
encompasses number and sizes of the parent's child windows too, which
can be retrieved only by looking at these child windows.  Also, a
vertical combination can be the parent of 2 or more internal windows, or
live and internal windows.

 >> By resizing their parent window or a sibling of their parent window.  Or
 >> by resizing the containing frame.  Or by resizing the minibuffer window.
 >
 > Some of these are unavailable to users.

... but maybe hidden in operations available to the user ...

 > We were talking about a user
 > option.

... which is hard to explain, I know.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juri Linkov]

>>> BTW this bug has been first described by Juri in Message#65 of Bug#1806.
>>
>> I see. Was there ever a conclusion reached?
>
> No.

Are we waiting for a conclusion whether to set `window-nest' to t by default
or to bind it individually where necessary?  Are there other options?

>> Ibuffer has the same issue, btw.
>
> More will turn up.

In Message#45 of Bug#1806 you already found more:

`Electric-pop-up-window', `ibuffer-confirm-operation-on',
`disabled-command-function', `proced-send-signal',
`fancy-startup-screen', `display-time-world', `widget-choose'.

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 > Are we waiting for a conclusion whether to set `window-nest' to t by default
 > or to bind it individually where necessary?

Setting it to t by default and _not_ binding it individually will have
detrimental consequences for people who don't want it always t.  Juanma
wants it always t because he wants to control the layout of his windows.
I'm more sloppy in this respect.  Hence if we choose to handle this via
`window-nest' we should bind that individually.

 > Are there other options?

You could try writing a suitable buffer display function ;-)

 >>> Ibuffer has the same issue, btw.
 >> More will turn up.
 >
 > In Message#45 of Bug#1806 you already found more:
 >
 > `Electric-pop-up-window', `ibuffer-confirm-operation-on',
 > `disabled-command-function', `proced-send-signal',
 > `fancy-startup-screen', `display-time-world', `widget-choose'.

I forgot about these.  Must have been some quick random search.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juri Linkov]

>> Are we waiting for a conclusion whether to set `window-nest' to t by default
>> or to bind it individually where necessary?
>
> Setting it to t by default and _not_ binding it individually will have
> detrimental consequences for people who don't want it always t.  Juanma
> wants it always t because he wants to control the layout of his windows.
> I'm more sloppy in this respect.  Hence if we choose to handle this via
> `window-nest' we should bind that individually.
>
>> Are there other options?
>
> You could try writing a suitable buffer display function ;-)

Below is a new buffer display function created from `dired-pop-to-buffer'
that can be used in all packages that need this functionality like
Dired and Proced (more could be fixed later if this is the right approach):

=== modified file 'lisp/window.el'
--- lisp/window.el	2011-10-30 08:29:56 +0000
+++ lisp/window.el	2011-10-31 10:05:16 +0000
@@ -4851,6 +4851,24 @@ (defun display-buffer-pop-up-window (buf
       (set-window-prev-buffers window nil)
       window)))
 
+(defun display-buffer-pop-up-window-below (buffer alist)
+  "Display BUFFER by popping up a new window below the selected window."
+  (let (
+	;; Stay within the confines of the initial window.
+	;; Don't resize other windows.  (Bug#1806 Bug#9873)
+	(window-nest t)
+	(split-window-preferred-function
+	 (lambda (window)
+	   (or (and (let ((split-height-threshold 0))
+		      (window-splittable-p (selected-window)))
+		    ;; Try to split the selected window vertically if
+		    ;; that's possible.  (Bug#1806)
+		    (split-window-below))
+	       ;; Otherwise, try to split WINDOW sensibly.
+	       (split-window-sensibly window))))
+	pop-up-frames)
+    (display-buffer-pop-up-window buffer alist)))
+
 (defun display-buffer--maybe-pop-up-frame-or-window (buffer alist)
   "Try displaying BUFFER based on `pop-up-frames' or `pop-up-windows'.
 
=== modified file 'lisp/dired.el'
--- lisp/dired.el	2011-10-30 01:56:03 +0000
+++ lisp/dired.el	2011-10-31 10:06:19 +0000
@@ -2873,17 +2873,7 @@ (defun dired-mark-prompt (arg files)
 
 (defun dired-pop-to-buffer (buf)
   "Pop up buffer BUF in a way suitable for Dired."
-  (let ((split-window-preferred-function
-	 (lambda (window)
-	   (or (and (let ((split-height-threshold 0))
-		      (window-splittable-p (selected-window)))
-		    ;; Try to split the selected window vertically if
-		    ;; that's possible.  (Bug#1806)
-		    (split-window-below))
-	       ;; Otherwise, try to split WINDOW sensibly.
-	       (split-window-sensibly window))))
-	pop-up-frames)
-    (pop-to-buffer (get-buffer-create buf)))
+  (pop-to-buffer (get-buffer-create buf) '(display-buffer-pop-up-window-below))
   ;; If dired-shrink-to-fit is t, make its window fit its contents.
   (when dired-shrink-to-fit
     ;; Try to not delete window when we want to display less than

=== modified file 'lisp/proced.el'
--- lisp/proced.el	2011-08-24 18:09:18 +0000
+++ lisp/proced.el	2011-10-31 10:07:56 +0000
@@ -1730,8 +1730,7 @@ (defun proced-send-signal (&optional sig
           (save-window-excursion
             ;; Analogous to `dired-pop-to-buffer'
             ;; Don't split window horizontally.  (Bug#1806)
-            (let (split-width-threshold)
-              (pop-to-buffer (current-buffer)))
+            (pop-to-buffer (current-buffer) '(display-buffer-pop-up-window-below))
             (fit-window-to-buffer (get-buffer-window) nil 1)
             (let* ((completion-ignore-case t)
                    (pnum (if (= 1 (length process-alist))

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

> +	pop-up-frames)

There should be no need to bind this to nil.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juri Linkov]

>> +	pop-up-frames)
>
> There should be no need to bind this to nil.

I agree it's unnecessary.  Below is a new patch without `pop-up-frames':

=== modified file 'lisp/window.el'
--- lisp/window.el	2011-11-02 09:39:18 +0000
+++ lisp/window.el	2011-11-03 19:34:58 +0000
@@ -4853,6 +4853,23 @@ (defun display-buffer-pop-up-window (buf
       (set-window-prev-buffers window nil)
       window)))
 
+(defun display-buffer-pop-up-window-below (buffer alist)
+  "Display BUFFER by popping up a new window below the selected window."
+  (let (
+	;; Stay within the confines of the initial window.
+	;; Don't resize other windows.  (Bug#1806 Bug#9873)
+	(window-nest t)
+	(split-window-preferred-function
+	 (lambda (window)
+	   (or (and (let ((split-height-threshold 0))
+		      (window-splittable-p (selected-window)))
+		    ;; Try to split the selected window vertically if
+		    ;; that's possible.  (Bug#1806)
+		    (split-window-below))
+	       ;; Otherwise, try to split WINDOW sensibly.
+	       (split-window-sensibly window)))))
+    (display-buffer-pop-up-window buffer alist)))
+
 (defun display-buffer--maybe-pop-up-frame-or-window (buffer alist)
   "Try displaying BUFFER based on `pop-up-frames' or `pop-up-windows'.
 

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juri Linkov]

>>> BTW this bug has been first described by Juri in Message#65 of Bug#1806.
>>
>> I see. Was there ever a conclusion reached?
>
> No.

Martin, what about bug#9873, can it be closed now?

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

 > Martin, what about bug#9873, can it be closed now?

Hopefully.  Interesting that you invented
`display-buffer-pop-up-window-below' then.  BTW, do we still have to fix
proced.el?  And what do we intend to do about these:

 > `Electric-pop-up-window', `ibuffer-confirm-operation-on',
 > `disabled-command-function', `proced-send-signal',
 > `fancy-startup-screen', `display-time-world', `widget-choose'.

martin

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[Juri Linkov]

>> Martin, what about bug#9873, can it be closed now?
>
> Hopefully.

Bug closed.

> BTW, do we still have to fix proced.el?
> And what do we intend to do about these:
>
>> `Electric-pop-up-window', `ibuffer-confirm-operation-on',
>> `disabled-command-function', `proced-send-signal',
>> `fancy-startup-screen', `display-time-world', `widget-choose'.

Eventually they should be fixed as well, but let's do this
in a separate bug report.

bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file

[martin rudalics]

> Eventually they should be fixed as well, but let's do this
> in a separate bug report.

I won't object ;-)

martin