bug#1806: dired-pop-to-buffer in wrong place

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

After 2008-12-11 change to window.el and dired.el that fixed the bug #1488,
I have difficulties using dired.

Before this change, running a dired operation on many files displayed
a pop-up window *below* the dired buffer and immediately *above* the
minibuffer.  This is the most convenient place to display a list of
file names, because it is near the minibuffer where the user types more
input for the command (a shell command or a directory to copy files to).

But now this list of files is displayed somewhere else - on the top of the
side window.  Thus now this list is as far for minibuffer as possible.
This is because `dired-pop-to-buffer' doesn't call `split-window' anymore
that used to split windows vertically even on a wide-screen display.

This is the same problem as I reported in
http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236
i.e. we need a special option to split windows vertically
where necessary.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > But now this list of files is displayed somewhere else - on the top of the
 > side window.  Thus now this list is as far for minibuffer as possible.
 > This is because `dired-pop-to-buffer' doesn't call `split-window' anymore
 > that used to split windows vertically even on a wide-screen display.
 >
 > This is the same problem as I reported in
 > http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236
 > i.e. we need a special option to split windows vertically
 > where necessary.

But that's what `split-width-threshold' is meant for.  Does
`dired-pop-to-buffer' DTRT when you set this to nil?

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> But now this list of files is displayed somewhere else - on the top of the
>> side window.  Thus now this list is as far for minibuffer as possible.
>> This is because `dired-pop-to-buffer' doesn't call `split-window' anymore
>> that used to split windows vertically even on a wide-screen display.
>>
>> This is the same problem as I reported in
>> http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236
>> i.e. we need a special option to split windows vertically
>> where necessary.
>
> But that's what `split-width-threshold' is meant for.  Does
> `dired-pop-to-buffer' DTRT when you set this to nil?

Yes, it works perfectly for Dired when `split-width-threshold' is nil.
But the problem is that I prefer a wide-screen configuration with
horizontally split windows, so I can't set `split-width-threshold' to nil.

There are a few exceptions where obeying non-nil `split-width-threshold'
is not desirable.  One exception is displaying a list of files in Dired,
and another is displaying the Calendar window.  Maybe there are a few
of others.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Yes, it works perfectly for Dired when `split-width-threshold' is nil.

Fine.

 > But the problem is that I prefer a wide-screen configuration with
 > horizontally split windows, so I can't set `split-width-threshold' to nil.
 >
 > There are a few exceptions where obeying non-nil `split-width-threshold'
 > is not desirable.  One exception is displaying a list of files in Dired,
 > and another is displaying the Calendar window.  Maybe there are a few
 > of others.

So the only thing we have to decide is whether we want to hardcode this
in `dired-pop-to-buffer' (and for the Calendar window and others) or
make it optional.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> There are a few exceptions where obeying non-nil `split-width-threshold'
>> is not desirable.  One exception is displaying a list of files in Dired,
>> and another is displaying the Calendar window.  Maybe there are a few
>> of others.
>
> So the only thing we have to decide is whether we want to hardcode this
> in `dired-pop-to-buffer' (and for the Calendar window and others) or
> make it optional.

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

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

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

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

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

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

Thanks, it now works for the one-window configuration.

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

We need a new special function in window.el that will do something
similar.

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

`proced-send-signal' is a recent change:

2009-01-03  Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>
	* proced.el (proced-send-signal):
        Use fit-window-to-buffer instead of dired-pop-to-buffer.

Roland, maybe we need a general function for both Proced and Dired?

> 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'.
>
> As for `calendar' I share Stefan's POV ...

Sorry, as a user of a wide-screen configuration I can't use
such layout.  Every time I run `calendar' I need manually fix
the layout by typing something like `C-x o C-x 2 C-x o C-x left C-x -'.
This is a real hassle!  For users who don't want a silly tall
mostly empty 70-line window we should have an option like
`dired-shrink-to-fit' to always show a 7-line window.

This layout also works well with the diary buffer:

    +------------+------------+
    |            |            |
    |            |            |
    |   diary    |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    +------------+            |
    |            |            |
    |  calendar  |            |
    |            |            |
    +------------+------------+

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.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > 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

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

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

Thank you, this works almost ideally.  The only problem I've encountered
is that sometimes it resizes existing windows:

    +------------+------------+        +------------+------------+
    |            |            |        |            |            |
    |            |            |        |            |            |
    |   dired    |   other2   |        |   dired    |   other2   |
    |            |            |        |            |            |
    |            |            |        +------------+            |
    |            |            |        | file list  |            |
    |            |            |  ===>  +------------+            |
    +------------+            |        |            |            |
    |            |            |        |            |            |
    |   other1   |            |        |   other1   |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    +------------+------------+        +------------+------------+

Please notice how the upper border of the lower window (other1)
was moved up.  I think it should keep the existing configuration
and create a new window at the cost of space from the original
dired buffer like this:

    +------------+------------+        +------------+------------+
    |            |            |        |            |            |
    |            |            |        |            |            |
    |   dired    |   other    |        |   dired    |   other    |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        +------------+            |
    |            |            |        | file list  |            |
    +------------+            |  ===>  +------------+            |
    |            |            |        |            |            |
    |   other    |            |        |   other    |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    +------------+------------+        +------------+------------+

As I can see currently `fit-window-to-buffer' always takes space
from the bottom window, but we need it from the top window.

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

I believe it would handle these cases.  Maybe it is possible to create
a single function e.g. `pop-to-buffer-below' that will display a new window
below from the current window taking its space.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > As I can see currently `fit-window-to-buffer' always takes space
 > from the bottom window, but we need it from the top window.

Not really.  `fit-window-to-buffer' uses `enlarge-window' which is our
idea of Robin Hood - stealing from the large, giving to the small.

An impractical solution is to make all other windows fixed-height and do
the fit.  This will almost certainly fail since deleting the window may
give its space to _any_ of its siblings.

A more practical solution would be to implement something like the
following: When a new window is created, remember the OLD _and_ the NEW
window configuration in the window's parameters.  When the window is
eventually deleted and the actual configuration "sufficiently" resembles
the NEW configuration, restore the OLD configuration.

martin

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

 > As I can see currently `fit-window-to-buffer' always takes space
 > from the bottom window, but we need it from the top window.

Looking at this again, I believe what you want is to invert the order of
stealing and giving as in the attached patch.  Might have side-effects
elsewhere.

martin

[-- Attachment #2: window.c.diff --]
[-- Type: text/plain, Size: 2433 bytes --]

Index: window.c
===================================================================
RCS file: /sources/emacs/emacs/src/window.c,v
retrieving revision 1.638
diff -c -r1.638 window.c
*** window.c	8 Jan 2009 03:16:08 -0000	1.638
--- window.c	8 Jan 2009 07:21:10 -0000
***************
*** 4125,4171 ****
        while (delta != 0
  	     && (!NILP (next) || !NILP (prev)))
  	{
! 	  if (! NILP (next))
  	    {
! 	      int this_one = ((*sizefun) (next)
! 			      - window_min_size (XWINDOW (next), horiz_flag,
  						 0, 0, &fixed_p));
  	      if (!fixed_p)
  		{
  		  if (this_one > delta)
  		    this_one = delta;
  
! 		  (*setsizefun) (next, (*sizefun) (next) - this_one, 0);
  		  (*setsizefun) (window, XINT (*sizep) + this_one, 0);
  
  		  delta -= this_one;
  		}
  
! 	      next = XWINDOW (next)->next;
  	    }
  
  	  if (delta == 0)
  	    break;
  
! 	  if (! NILP (prev))
  	    {
! 	      int this_one = ((*sizefun) (prev)
! 			      - window_min_size (XWINDOW (prev), horiz_flag,
  						 0, 0, &fixed_p));
  	      if (!fixed_p)
  		{
  		  if (this_one > delta)
  		    this_one = delta;
  
! 		  first_affected = prev;
! 
! 		  (*setsizefun) (prev, (*sizefun) (prev) - this_one, 0);
  		  (*setsizefun) (window, XINT (*sizep) + this_one, 0);
  
  		  delta -= this_one;
  		}
  
! 	      prev = XWINDOW (prev)->prev;
  	    }
  	}
  
--- 4125,4171 ----
        while (delta != 0
  	     && (!NILP (next) || !NILP (prev)))
  	{
! 	  if (! NILP (prev))
  	    {
! 	      int this_one = ((*sizefun) (prev)
! 			      - window_min_size (XWINDOW (prev), horiz_flag,
  						 0, 0, &fixed_p));
  	      if (!fixed_p)
  		{
  		  if (this_one > delta)
  		    this_one = delta;
  
! 		  first_affected = prev;
! 
! 		  (*setsizefun) (prev, (*sizefun) (prev) - this_one, 0);
  		  (*setsizefun) (window, XINT (*sizep) + this_one, 0);
  
  		  delta -= this_one;
  		}
  
! 	      prev = XWINDOW (prev)->prev;
  	    }
  
  	  if (delta == 0)
  	    break;
  
! 	  if (! NILP (next))
  	    {
! 	      int this_one = ((*sizefun) (next)
! 			      - window_min_size (XWINDOW (next), horiz_flag,
  						 0, 0, &fixed_p));
  	      if (!fixed_p)
  		{
  		  if (this_one > delta)
  		    this_one = delta;
  
! 		  (*setsizefun) (next, (*sizefun) (next) - this_one, 0);
  		  (*setsizefun) (window, XINT (*sizep) + this_one, 0);
  
  		  delta -= this_one;
  		}
  
! 	      next = XWINDOW (next)->next;
  	    }
  	}
  

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> As I can see currently `fit-window-to-buffer' always takes space
>> from the bottom window, but we need it from the top window.
>
> Looking at this again, I believe what you want is to invert the order of
> stealing and giving as in the attached patch.  Might have side-effects
> elsewhere.

Maybe a simpler solution is to change `fit-window-to-buffer'
so in such configurations when windows are split vertically
(the correct treating of horizontally split windows
is already provided in dired-pop-to-buffer you sent recently)
it will temporarily switch the current window to the upper window
and call `enlarge-window' from the upper window, thus resizing
the right border.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> Looking at this again, I believe what you want is to invert the order of
 >> stealing and giving as in the attached patch.  Might have side-effects
 >> elsewhere.
 >
 > Maybe a simpler solution

The change of `enlarge-window' _is_ simple - only the diff appears
complicated.  But we'd have to decide whether it's OK to steal from/give
to the previous window when enlarging a window.  (It makes a difference
only when we have at least three windows in a row or column.)

 > is to change `fit-window-to-buffer'
 > so in such configurations when windows are split vertically

We cannot change `fit-window-to-buffer' - it's used, for example, by
`resize-temp-buffer-window', not necessarily connected to splitting
windows at all.

 > (the correct treating of horizontally split windows
 > is already provided in dired-pop-to-buffer you sent recently)
 > it will temporarily switch the current window to the upper window
 > and call `enlarge-window' from the upper window, thus resizing
 > the right border.

We'd have to do this within the function that splits the Dired window.
I recently rewrote `fit-window-to-buffer' but still don't understand it
completely - in particular the (enlarge-window 1) loop.  Within that
loop we'd have to continuously switch to the Dired window in order too
enlarge it.  I'd rather avoid such hairy switches.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>>> Looking at this again, I believe what you want is to invert the order of
>>> stealing and giving as in the attached patch.  Might have side-effects
>>> elsewhere.
>>
>> Maybe a simpler solution
>
> The change of `enlarge-window' _is_ simple - only the diff appears
> complicated.  But we'd have to decide whether it's OK to steal from/give
> to the previous window when enlarging a window.  (It makes a difference
> only when we have at least three windows in a row or column.)

I've just looked at the old behavior from the December CVS state,
and noticed that it behaved more conveniently than we are currently
discussing.  It displayed a list of files immediately above the
minibuffer.  This is convenient because when the minibuffer says:

  ! on * [5 files]:

then a list of these 5 files is very near above, so there is no need
to search for this list elsewhere on the current frame.  Maybe we
should have a special function to display a buffer above the minibuffer
(e.g. `pop-to-buffer-above-minibuffer')?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Maybe we
 > should have a special function to display a buffer above the minibuffer
 > (e.g. `pop-to-buffer-above-minibuffer')?

But when you have vertically-split windows and the *dired* buffer
appears on top of the frame, there may be another window between the
*dired* window and the *Marked files* window.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Maybe we should have a special function to display a buffer above the
>> minibuffer (e.g. `pop-to-buffer-above-minibuffer')?

> But when you have vertically-split windows and the *dired* buffer
> appears on top of the frame, there may be another window between the
> *dired* window and the *Marked files* window.

And that's good: the list should be close to the question, not close to
the dired buffer.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > And that's good: the list should be close to the question, not close to
 > the dired buffer.

If the dired buffer were not needed while asking the question, dired
could temporarily display that list in the dired window itself and
switch back to the dired buffer afterwards.  But I never use dired.

What about putting this in `pop-up-windows'?  Possible values are:

nil		do not allow popping up windows
'this		selected window
'below	  	below selected window
'below-split	split selected window vertically
'right		right of selected window
'right-split	split selected window horizontally
'bottom		use window near bottom of frame
'bottom-split	split window near bottom of frame
t		allow popping up windows

If an application (like dired) sees that this variable is t (the
default) it may ask to pop up the window wherever it's most suitable.
Otherwise, it has to respect the value chosen by the user.  Like

(let ((pop-up-windows (if (eq pop-up-windows t)
			  'bottom-split
			pop-up-windows)))
   (display-buffer ...))

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> What about putting this in `pop-up-windows'?  Possible values are:

> nil		do not allow popping up windows
> 'this		selected window
> 'below	  	below selected window
> 'below-split	split selected window vertically
> 'right		right of selected window
> 'right-split	split selected window horizontally
> 'bottom		use window near bottom of frame
> 'bottom-split	split window near bottom of frame
> t		allow popping up windows

> If an application (like dired) sees that this variable is t (the
> default) it may ask to pop up the window wherever it's most suitable.
> Otherwise, it has to respect the value chosen by the user.  Like

> (let ((pop-up-windows (if (eq pop-up-windows t)
> 			  'bottom-split
> 			pop-up-windows)))
>   (display-buffer ...))

But how would the user override this behavior in a way that can depend
on the buffer being shown (i.e. via special-display-buffer-names)?


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > But how would the user override this behavior in a way that can depend
 > on the buffer being shown (i.e. via special-display-buffer-names)?

Customizing `pop-up-windows' would give (1) a general preference where
and how `display-buffer' should pop up windows, and (2) a possibility to
override decisions made by applications like dired on where and how to
pop up windows.

`special-display-buffer-names' and `special-display-regexps' would be
handled as usually, before checking `pop-up-windows'.  If we want, we
can provide things like 'window-below or 'window-at-bottom as phony
parameters as suggested earlier.

All this is also a question of where and how to document behavior best.
I tried to understand and document the special-display stuff but am
pretty sure that I still haven't got it right yet.  I strongly doubt
that anyone but you really knows how this is supposed to work.

OTOH `pop-up-windows' has a one line doc-string, so I thought we could
try that first.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> But how would the user override this behavior in a way that can depend
>> on the buffer being shown (i.e. via special-display-buffer-names)?

> Customizing `pop-up-windows' would give (1) a general preference where
> and how `display-buffer' should pop up windows, and (2) a possibility to
> override decisions made by applications like dired on where and how to
> pop up windows.

> `special-display-buffer-names' and `special-display-regexps' would be
> handled as usually, before checking `pop-up-windows'.  If we want, we
> can provide things like 'window-below or 'window-at-bottom as phony
> parameters as suggested earlier.

Actually, those phony params aren't right.  Now that you made me think
some more about it, they're all mutually exclusive, so we really only
want one such param whose value could be `same-frame', `same-window',
or `near-minibuffer'.  Those same values could be used for
pop-up-windows.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> `special-display-buffer-names' and `special-display-regexps' would be
>> handled as usually, before checking `pop-up-windows'.  If we want, we
>> can provide things like 'window-below or 'window-at-bottom as phony
>> parameters as suggested earlier.
>
> Actually, those phony params aren't right.  Now that you made me think
> some more about it, they're all mutually exclusive, so we really only
> want one such param whose value could be `same-frame', `same-window',
> or `near-minibuffer'.  Those same values could be used for
> pop-up-windows.

While at this topic, could you also suggest a good parameter for the
name of the current buffer to define where to display a new buffer.
What I mean is that, for example, after clicking a link to the source file
from the *Help* buffer, I want the source code (c. or .el) buffer to be
displayed in the same window replacing the *Help* buffer.  Since the name
of the source code buffer can be anything, the only definite parameter is
the name of the last buffer displayed in the current window ("*Help*").

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:

>>> `special-display-buffer-names' and `special-display-regexps' would be
>>> handled as usually, before checking `pop-up-windows'.  If we want, we
>>> can provide things like 'window-below or 'window-at-bottom as phony
>>> parameters as suggested earlier.
>> 
>> Actually, those phony params aren't right.  Now that you made me think
>> some more about it, they're all mutually exclusive, so we really only
>> want one such param whose value could be `same-frame', `same-window',
>> or `near-minibuffer'.  Those same values could be used for
>> pop-up-windows.

> While at this topic, could you also suggest a good parameter for the
> name of the current buffer to define where to display a new buffer.
> What I mean is that, for example, after clicking a link to the source file
> from the *Help* buffer, I want the source code (c. or .el) buffer to be
> displayed in the same window replacing the *Help* buffer.  Since the name
> of the source code buffer can be anything, the only definite parameter is
> the name of the last buffer displayed in the current window ("*Help*").

Not sure 'bout that.  Probably special-display-buffer-names is not the
bext place to use for that kind of information.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Please have a look at the attached (only lightly tested) patch.  I
didn't provide a similar service for `special-display-buffer-names' and
`special-display-regexps' yet.

`display-buffer' and `pop-to-buffer' behave "as usual" as long as the
default values for `pop-up-windows', NOT-THIS-WINDOW, and OTHER-WINDOW
are used.  An application calling `display-buffer' or `pop-to-buffer'
can specify the preferable window to split by setting NOT-THIS-WINDOW or
OTHER-WINDOW appropriately.  Users can specify their preferences (and
override the application) by setting `pop-up-windows' appropriately.

martin



[-- Attachment #2: window.el.diff --]
[-- Type: text/plain, Size: 11572 bytes --]

*** window.el.~1.179.~	2009-01-16 17:41:41.046875000 +0100
--- window.el	2009-01-20 16:58:01.062500000 +0100
***************
*** 789,797 ****
    :version "21.1"
    :group 'windows)
  
  (defcustom pop-up-windows t
!   "Non-nil means `display-buffer' should make a new window."
!   :type 'boolean
    :group 'windows)
  
  (defcustom split-height-threshold 80
--- 789,843 ----
    :version "21.1"
    :group 'windows)
  
+ ;; Make sure the following two variables always use the same values
+ ;; (sans `t').
+ (defconst pop-up-windows-values
+   '(largest lru selected below right bottom-left top-left)
+   "List of preferences supported by `pop-up-windows'.")
+ 
  (defcustom pop-up-windows t
!   "Non-nil means `display-buffer' is allowed to make a new window.
! A non-empty list specifies the windows `display-buffer' will
! consider for splitting on the respective frame.  The following
! entries are supported:
! 
!  largest ...... largest window
!  lru .......... least recently used window
!  selected ..... the frame's selected window
!  below ........ window below frame's selected window
!  right ........ window right of frame's selected window
!  bottom-left .. window in lower left corner of frame
!  top-left ..... window in upper left corner of frame
!  t ............ window specified by application
! 
! Note that when `display-buffer' finds the value t, it will use
! the value specified by the function that called `display-buffer'
! provided there is one, and ignore this entry otherwise.  If the
! entire list equals `(t)', `display-buffer' will pop up a new
! window if and only if the application specified value produces
! one.  If this list does not contain the value t, `display-buffer'
! will ignore any value specified by an application.
! 
! The default value t stands for the list `(t largest lru)'.  This
! means that Emacs will first try a value specified by the
! application that called `display-buffer'.  If there's no such
! value, or the window specified by that value doesn't exist, or
! that window can't be split, `display-buffer' will try to split
! the largest window and, if that fails too, the least recently
! used window."
!   :type '(choice
! 	  (const :tag "Disallow" nil)
! 	  (const :tag "Allow" t)
! 	  (repeat :tag "Preferences"
! 		  (choice
! 		   (const :tag "Largest" largest)
! 		   (const :tag "Least Recently Used" lru)
! 		   (const :tag "Selected" selected)
! 		   (const :tag "Below Selected" below)
! 		   (const :tag "Right of Selected" right)
! 		   (const :tag "Bottom Left" bottom-left)
! 		   (const :tag "Top Left" top-left)
! 		   (const :tag "Application Specified" t))))
    :group 'windows)
  
  (defcustom split-height-threshold 80
***************
*** 957,962 ****
--- 1003,1099 ----
  	  (enlarge-window (/ (- (window-height window) (window-height)) 2))
  	(error nil)))))
  
+ (defun window--probe-windows (frame windows probe)
+   "Find window in WINDOWS satisfying PROBE on FRAME.
+ To be called by `window--pop-up-window' exclusively."
+   (cond
+    ((eq probe 'selected)
+     (let ((window (frame-selected-window frame)))
+       (car (member window windows))))
+    ((eq probe 'largest)
+     (get-largest-window frame t))
+    ((eq probe 'lru)
+     (get-lru-window frame t))
+    ((memq probe '(below right bottom-left top-left))
+     (let ((this-edges
+ 	   (window-edges
+ 	    (cond
+ 	     ((memq probe '(below right))
+ 	      (frame-selected-window frame))
+ 	     ((memq probe '(top-left bottom-left))
+ 	      (frame-root-window frame)))))
+ 	  edges)
+       (catch 'found
+ 	(dolist (window windows)
+ 	  (setq edges (window-edges window))
+ 	  (when (or (and (eq probe 'below)
+ 			 (= (nth 1 edges) (nth 3 this-edges))
+ 			 (= (nth 2 edges) (nth 2 this-edges)))
+ 		    (and (eq probe 'right)
+ 			 (= (nth 0 edges) (nth 2 this-edges))
+ 			 (= (nth 1 edges) (nth 1 this-edges)))
+ 		    (and (eq probe 'top-left)
+ 			 (= (nth 0 edges) (nth 0 this-edges))
+ 			 (= (nth 1 edges) (nth 1 this-edges)))
+ 		    (and (eq probe 'bottom-left)
+ 			 (= (nth 0 edges) (nth 0 this-edges))
+ 			 (= (nth 3 edges) (nth 3 this-edges))))
+ 	    (throw 'found window))))))))
+ 
+ (defun window--pop-up-window (buffer frame user system)
+   "Pop up a new window for BUFFER on FRAME.
+ FRAME nil means the selected frame.  If FRAME cannot be split,
+ try to split a window on the last nonminibuffer frame instead.
+ 
+ USER, if not nil and not t, is a list specifying the user's
+ preferences for finding the window to split.  For a list of
+ supported values see the variable `pop-up-windows-values'.  The
+ special value t means to use SYSTEM, if applicable, instead.  For
+ the meaning of all values, consult the documentation of the
+ variable `pop-up-windows'.  If USER equals t, this means to use
+ the list `(t largest lru)' instead.
+ 
+ SYSTEM, provided it is any of `pop-up-windows-values',
+ substitutes an occurence of t within USER."
+   ;; FRAME nil means use the selected frame.
+   (setq frame (or frame (selected-frame)))
+   ;; But make sure our frame is not a minibuffer frame.
+   (when (window-minibuffer-p (frame-selected-window frame))
+     (setq frame (last-nonminibuffer-frame)))
+   (unless (and (frame-parameter frame 'unsplittable)
+ 	       ;; If the frame cannot be split have a look at
+ 	       ;; `last-nonminibuffer-frame'.
+ 	       (or (not (eq frame (selected-frame)))
+ 		   (not (setq frame (last-nonminibuffer-frame)))
+ 		   (not (window--frame-usable-p frame))
+ 		   (frame-parameter frame 'unsplittable)))
+     (when (eq user t)
+       ;; USER t means use '(t largest lru) instead.
+       (setq user '(t largest lru)))
+     (let* ((this-window (frame-selected-window frame))
+ 	   (windows (window-list frame 'nomini this-window))
+ 	   (probe (car user))
+ 	   window window-to-use)
+       ;; While we have not yet found a usable window, scan `windows' for
+       ;; a windows satisfying `probe'.
+       (while (and (not window-to-use) windows probe)
+ 	(setq window
+ 	      (if (eq probe t)
+ 		  ;; SYSTEM overrides t in USER.
+ 		  (when (memq system pop-up-windows-values)
+ 		    ;; SYSTEM is a valid value, so use it.
+ 		    (window--probe-windows frame windows system))
+ 		(window--probe-windows frame windows probe)))
+ 	(when window
+ 	  (setq window-to-use (window--try-to-split-window window)))
+ 	(unless window-to-use
+ 	  ;; Don't consider `window' again.
+ 	  (setq windows (remove window windows))
+ 	  (setq user (cdr user))
+ 	  (setq probe (car user))))
+       (when window-to-use
+ 	(window--display-buffer-2 buffer window-to-use)))))
+ 
  (defun window--display-buffer-1 (window)
    "Raise the frame containing WINDOW.
  Do not raise the selected frame.  Return WINDOW."
***************
*** 987,993 ****
  
  Optional argument NOT-THIS-WINDOW non-nil means display the
  buffer in a window other than the selected one, even if it is
! already displayed in the selected window.
  
  Optional argument FRAME specifies which frames to investigate
  when the specified buffer is already displayed.  If the buffer is
--- 1124,1135 ----
  
  Optional argument NOT-THIS-WINDOW non-nil means display the
  buffer in a window other than the selected one, even if it is
! already displayed in the selected window.  As a special case, if
! NOT-THIS-WINDOW is any of the values in `pop-up-windows-values',
! this means to use that for finding a window to split.  The
! documentation of the variable `pop-up-windows' contains an
! explanation of what these values mean as well as when such a
! value is applied.
  
  Optional argument FRAME specifies which frames to investigate
  when the specified buffer is already displayed.  If the buffer is
***************
*** 1009,1017 ****
  consider all visible or iconified frames."
    (interactive "BDisplay buffer:\nP")
    (let* ((can-use-selected-window
! 	  ;; The selected window is usable unless either NOT-THIS-WINDOW
! 	  ;; is non-nil, it is dedicated to its buffer, or it is the
! 	  ;; `minibuffer-window'.
  	  (not (or not-this-window
  		   (window-dedicated-p (selected-window))
  		   (window-minibuffer-p))))
--- 1151,1159 ----
  consider all visible or iconified frames."
    (interactive "BDisplay buffer:\nP")
    (let* ((can-use-selected-window
! 	  ;; The selected window is usable unless either
! 	  ;; NOT-THIS-WINDOW is non-nil, it is dedicated to its
! 	  ;; buffer, or it is the `minibuffer-window'.
  	  (not (or not-this-window
  		   (window-dedicated-p (selected-window))
  		   (window-minibuffer-p))))
***************
*** 1039,1046 ****
        (funcall display-buffer-function buffer not-this-window))
       ((and (not not-this-window)
  	   (eq (window-buffer (selected-window)) buffer))
!       ;; The selected window already displays BUFFER and
!       ;; `not-this-window' is nil, so use it.
        (window--display-buffer-1 (selected-window)))
       ((and can-use-selected-window (same-window-p name-of-buffer))
        ;; If the buffer's name tells us to use the selected window do so.
--- 1181,1188 ----
        (funcall display-buffer-function buffer not-this-window))
       ((and (not not-this-window)
  	   (eq (window-buffer (selected-window)) buffer))
!       ;; The selected window already displays BUFFER and NOT-THIS-WINDOW
!       ;; is nil, so use it.
        (window--display-buffer-1 (selected-window)))
       ((and can-use-selected-window (same-window-p name-of-buffer))
        ;; If the buffer's name tells us to use the selected window do so.
***************
*** 1073,1093 ****
        (window--display-buffer-2
         buffer (frame-selected-window (funcall pop-up-frame-function))))
       ((and pop-up-windows
! 	   ;; Make a new window.
! 	   (or (not (frame-parameter frame-to-use 'unsplittable))
! 	       ;; If the selected frame cannot be split look at
! 	       ;; `last-nonminibuffer-frame'.
! 	       (and (eq frame-to-use (selected-frame))
! 		    (setq frame-to-use (last-nonminibuffer-frame))
! 		    (window--frame-usable-p frame-to-use)
! 		    (not (frame-parameter frame-to-use 'unsplittable))))
! 	   ;; Attempt to split largest or least recently used window.
! 	   (setq window-to-use
! 		 (or (window--try-to-split-window
! 		      (get-largest-window frame-to-use t))
! 		     (window--try-to-split-window
! 		      (get-lru-window frame-to-use t))))
! 	   (window--display-buffer-2 buffer window-to-use)))
       ((let ((window-to-undedicate
  	     ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate
  	     ;; the selected window to its buffer, to avoid that some of
--- 1215,1222 ----
        (window--display-buffer-2
         buffer (frame-selected-window (funcall pop-up-frame-function))))
       ((and pop-up-windows
! 	   (window--pop-up-window
! 	    buffer frame-to-use pop-up-windows not-this-window)))
       ((let ((window-to-undedicate
  	     ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate
  	     ;; the selected window to its buffer, to avoid that some of
***************
*** 1129,1134 ****
--- 1258,1269 ----
  already visible in the selected window, and ignore
  `same-window-regexps' and `same-window-buffer-names'.
  
+ As a special case, if OTHER-WINDOW is any of the values in
+ `pop-up-windows-values', this means to use that value for finding
+ a suitable window to split.  The documentation of the variable
+ `pop-up-windows' contains an explanation of what these values
+ mean as well as when such a value is applied.
+ 
  If the window to show BUFFER-OR-NAME is not on the selected
  frame, raise that window's frame and give it input focus.
  

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> Please have a look at the attached (only lightly tested) patch.  I
> didn't provide a similar service for `special-display-buffer-names' and
> `special-display-regexps' yet.

> `display-buffer' and `pop-to-buffer' behave "as usual" as long as the
> default values for `pop-up-windows', NOT-THIS-WINDOW, and OTHER-WINDOW
> are used.  An application calling `display-buffer' or `pop-to-buffer'
> can specify the preferable window to split by setting NOT-THIS-WINDOW or
> OTHER-WINDOW appropriately.  Users can specify their preferences (and
> override the application) by setting `pop-up-windows' appropriately.

I think this is post-23.1.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> Please have a look at the attached (only lightly tested) patch.
> I didn't provide a similar service for `special-display-buffer-names'
> and `special-display-regexps' yet.
>
> `display-buffer' and `pop-to-buffer' behave "as usual" as long as the
> default values for `pop-up-windows', NOT-THIS-WINDOW, and OTHER-WINDOW
> are used.  An application calling `display-buffer' or `pop-to-buffer'
> can specify the preferable window to split by setting NOT-THIS-WINDOW or
> OTHER-WINDOW appropriately.  Users can specify their preferences (and
> override the application) by setting `pop-up-windows' appropriately.

This might be good for post-23.1, but the reported annoyance is still here,
so we need just to restore the old 22.1 behavior of `dired-pop-to-buffer'.

Martin, do you think this is possible without reverting `dired-pop-to-buffer'
to pre-December 2008 state, and making necessary changes in window.el
thus providing the same behavior that was in `dired-pop-to-buffer'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > This might be good for post-23.1, but the reported annoyance is still here,
 > so we need just to restore the old 22.1 behavior of `dired-pop-to-buffer'.
 >
 > Martin, do you think this is possible without reverting `dired-pop-to-buffer'
 > to pre-December 2008 state, and making necessary changes in window.el
 > thus providing the same behavior that was in `dired-pop-to-buffer'?

`dired-pop-to-buffer' could bind `split-window-preferred-function' to a
function that tries to always split the selected window instead of
whatever window was chosen by `display-buffer' but that would override
any user customizations of `split-window-preferred-function'.

We could also provide a variable `split-window-preferred-window', nil by
default, which the window choosing mechanism of `display-buffer' would
respect if bound to some live window.  And we could turn this variable
into an option (now or later).

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> This might be good for post-23.1, but the reported annoyance is still here,
>> so we need just to restore the old 22.1 behavior of `dired-pop-to-buffer'.
>>
>> Martin, do you think this is possible without reverting `dired-pop-to-buffer'
>> to pre-December 2008 state, and making necessary changes in window.el
>> thus providing the same behavior that was in `dired-pop-to-buffer'?
>
> `dired-pop-to-buffer' could bind `split-window-preferred-function' to a
> function that tries to always split the selected window instead of
> whatever window was chosen by `display-buffer' but that would override
> any user customizations of `split-window-preferred-function'.

We could compare `split-window-preferred-function' with its default value
and override it in dired only when it has the default value.

Otherwise we could define a new option `dired-split-window-preferred-function'.

> We could also provide a variable `split-window-preferred-window', nil by
> default, which the window choosing mechanism of `display-buffer' would
> respect if bound to some live window.  And we could turn this variable
> into an option (now or later).

Do you mean `split-window-preferred-window' as a user-defined value
that replaces the `window' argument of `split-window-preferred-function'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > We could compare `split-window-preferred-function' with its default value
 > and override it in dired only when it has the default value.

It would be more difficult to document such behavior than to implement it.

 > Otherwise we could define a new option `dired-split-window-preferred-function'.

Didn't you cite some other package that wanted such a thing?

 >> We could also provide a variable `split-window-preferred-window', nil by
 >> default, which the window choosing mechanism of `display-buffer' would
 >> respect if bound to some live window.  And we could turn this variable
 >> into an option (now or later).
 >
 > Do you mean `split-window-preferred-window' as a user-defined value
 > that replaces the `window' argument of `split-window-preferred-function'?

Yes, provided `split-window-preferred-function' then still wants such an
argument.  I'd simply check whether `split-window-preferred-window' is a
live window that can be split by `split-window-preferred-function'.  If
not, I'd proceed in the usual way.  Later on, we could allow as value of
`split-window-preferred-window' also a function that computes such a
window on-the-fly.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> Didn't you cite some other package that wanted such a thing?

Yes, Proced, Calendar, etc.  I believe it is possible to define
one common splitting function (that finds the right window to split
and splits it vertically) for all these packages in window.el,
but I still think even this common function should be customizable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> `dired-pop-to-buffer' could bind `split-window-preferred-function' to a
> function that tries to always split the selected window instead of
> whatever window was chosen by `display-buffer' but that would override
> any user customizations of `split-window-preferred-function'.

Why would it override it?  It would of course bind
split-window-preferred-function to a function that selects the right
window and then calls the previous value.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Why would it override it?  It would of course bind
 > split-window-preferred-function to a function that selects the right
 > window and then calls the previous value.

Maybe you can come up with some advanced technique to do that but here I
would have to define a variable to save the current (user provided)
`split-window-preferred-function' and call the function I save there
within the body of the function provided by dired.  Hence an extra
variable would be needed anyway and I suppose it's easier to define that
in window.el rather than in all packages that want to change the window
to split (IIRC Calendar was one of these).

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Why would it override it?  It would of course bind
>> split-window-preferred-function to a function that selects the right
>> window and then calls the previous value.

> Maybe you can come up with some advanced technique to do that but here I
> would have to define a variable to save the current (user provided)
> `split-window-preferred-function' and call the function I save there
> within the body of the function provided by dired.

I'd use something like

  (lexical-let ((oldfun split-window-preferred-function))
    (let ((split-window-preferred-function
           (lambda () (with-selected-window TOTO (funcall oldfun)))))
      BLABLA))

> Hence an extra variable would be needed anyway and I suppose it's
> easier to define that in window.el rather than in all packages that
> want to change the window to split (IIRC Calendar was one of these).

The above coding should be close to "standard practice" for locally
rebinding a *-function variable.  The "extra variable" doesn't matter,
it's not like we count variables.

Maybe what you're getting at is that we should make a hook to influence
the window-choice.  Maybe so.  But it doesn't seem urgent.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

 >> Maybe you can come up with some advanced technique to do that but here I
 >> would have to define a variable to save the current (user provided)
 >> `split-window-preferred-function' and call the function I save there
 >> within the body of the function provided by dired.
 >
 > I'd use something like
 >
 >   (lexical-let ((oldfun split-window-preferred-function))
 >     (let ((split-window-preferred-function
 >            (lambda () (with-selected-window TOTO (funcall oldfun)))))
 >       BLABLA))

We probably need something like in the attached patch but my knowledge
of closures within Elisp is very limited.

 > The above coding should be close to "standard practice" for locally
 > rebinding a *-function variable.  The "extra variable" doesn't matter,
 > it's not like we count variables.
 >
 > Maybe what you're getting at is that we should make a hook to influence
 > the window-choice.  Maybe so.  But it doesn't seem urgent.

I was aiming at an extra variable to work around "advanced techniques"
like closures.  `lexical-let' doesn't even indent reasonably :-(

martin

[-- Attachment #2: dired.el.diff --]
[-- Type: text/plain, Size: 1074 bytes --]

*** dired.el.~1.422.~	2009-04-18 08:32:56.546875000 +0200
--- dired.el	2009-05-01 11:47:49.109375000 +0200
***************
*** 2686,2694 ****
  
  (defun dired-pop-to-buffer (buf)
    "Pop up buffer BUF in a way suitable for Dired."
!   ;; Don't split window horizontally.  (Bug#1806)
!   (let (split-width-threshold)
!     (pop-to-buffer (get-buffer-create buf)))
    ;; 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
--- 2686,2696 ----
  
  (defun dired-pop-to-buffer (buf)
    "Pop up buffer BUF in a way suitable for Dired."
!   (lexical-let ((old-fun split-window-preferred-function)
! 		(old-window (selected-window)))
!     (let ((split-window-preferred-function
! 	   (lambda () (with-selected-window old-window (funcall old-fun)))))
!       (pop-to-buffer (get-buffer-create buf))))
    ;; 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

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> We probably need something like in the attached patch but my knowledge
> of closures within Elisp is very limited.

That looks fine.

> I was aiming at an extra variable to work around "advanced techniques"
> like closures.

Closures are (should be) bread&butter; not "advanced".

> `lexical-let' doesn't even indent reasonably :-(

I don't know of any such bug, so please give details.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Closures are (should be) bread&butter; not "advanced".
 >
 >> `lexical-let' doesn't even indent reasonably :-(
 >
 > I don't know of any such bug, so please give details.

It won't indent correctly from scratch.  I do have to load the CL
library first which hardly qualifies as bread&butter ;-)

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Closures are (should be) bread&butter; not "advanced".
>>> `lexical-let' doesn't even indent reasonably :-(
>> I don't know of any such bug, so please give details.
> It won't indent correctly from scratch.  I do have to load the CL
> library first which hardly qualifies as bread&butter ;-)

`lexical-let' is specific to Emacs.  Closures are not.
`lexical-let' is a hack.  Closures are not.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > `lexical-let' is specific to Emacs.  Closures are not.
 > `lexical-let' is a hack.  Closures are not.

That's precisely what I had in mind but was afraid to say.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>   (defun dired-pop-to-buffer (buf)
>     "Pop up buffer BUF in a way suitable for Dired."
> !   ;; Don't split window horizontally.  (Bug#1806)
> !   (let (split-width-threshold)
> !     (pop-to-buffer (get-buffer-create buf)))
>     ;; 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
> --- 2686,2696 ----
>   
>   (defun dired-pop-to-buffer (buf)
>     "Pop up buffer BUF in a way suitable for Dired."
> !   (lexical-let ((old-fun split-window-preferred-function)
> ! 		(old-window (selected-window)))
> !     (let ((split-window-preferred-function
> ! 	   (lambda () (with-selected-window old-window (funcall old-fun)))))
> !       (pop-to-buffer (get-buffer-create buf))))
>     ;; 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

Is your patch intended to fix a problem I reported?  I tried it and
it makes the current state worse.  It works incorrectly even in the
one-window configuration - it splits it horizontally and displays
a list of files in a side window.

However, when I replaced

  (funcall old-fun)

with

  (funcall 'split-window-vertically)

in your patch, it works perfectly in all configurations I tried.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Is your patch intended to fix a problem I reported?

Hopefully.

 > I tried it and
 > it makes the current state worse.  It works incorrectly even in the
 > one-window configuration - it splits it horizontally and displays
 > a list of files in a side window.

Did you try it after applying my patch for window.el?

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> Is your patch intended to fix a problem I reported?
>
> Hopefully.
>
>> I tried it and
>> it makes the current state worse.  It works incorrectly even in the
>> one-window configuration - it splits it horizontally and displays
>> a list of files in a side window.
>
> Did you try it after applying my patch for window.el?

Yes, with your patch for window.el and in a frame wider than 160 columns.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

 >> Did you try it after applying my patch for window.el?
 >
 > Yes, with your patch for window.el and in a frame wider than 160 columns.

My bad.  Does the attached patch give better results?

martin

[-- Attachment #2: dired.el.diff --]
[-- Type: text/plain, Size: 1122 bytes --]

*** dired.el.~1.422.~	2009-04-18 08:32:56.546875000 +0200
--- dired.el	2009-05-02 20:49:03.656250000 +0200
***************
*** 2686,2694 ****
  
  (defun dired-pop-to-buffer (buf)
    "Pop up buffer BUF in a way suitable for Dired."
!   ;; Don't split window horizontally.  (Bug#1806)
!   (let (split-width-threshold)
!     (pop-to-buffer (get-buffer-create buf)))
    ;; 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
--- 2686,2698 ----
  
  (defun dired-pop-to-buffer (buf)
    "Pop up buffer BUF in a way suitable for Dired."
!   (lexical-let ((old-fun split-window-preferred-function)
! 		(old-window (selected-window)))
!     (let ((split-window-preferred-function
! 	   (lambda ()
! 	     (let (split-width-threshold)
! 	       (with-selected-window old-window (funcall old-fun))))))
!       (pop-to-buffer (get-buffer-create buf))))
    ;; 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

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>>> Did you try it after applying my patch for window.el?
>>
>> Yes, with your patch for window.el and in a frame wider than 160 columns.
>
> My bad.  Does the attached patch give better results?

It is no much better than your previous patch - when windows are already
split horizontally, it displays a list of files in the side window instead
of vertically splitting the dired buffer's window and creating a new
window below it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> However, when I replaced
>
>   (funcall old-fun)
>
> with
>
>   (funcall 'split-window-vertically)
>
> in your patch, it works perfectly in all configurations I tried.

I still think `split-window-vertically' is more appropriate because
in a dired buffer it should unconditionally split the original window
vertically.  In such situations `split-window-sensibly' is
the wrong method
with the wrong technique

It displays a new window
in the wrong place
at the wrong time

For the wrong reason and
the wrong rhyme

On the wrong day of
the wrong week

Wrong

Wrong

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > I still think `split-window-vertically' is more appropriate because
 > in a dired buffer it should unconditionally split the original window
 > vertically.  In such situations `split-window-sensibly' is
 > the wrong method
 > with the wrong technique
 >
 > It displays a new window
 > in the wrong place
 > at the wrong time
 >
 > For the wrong reason and
 > the wrong rhyme
 >
 > On the wrong day of
 > the wrong week
 >
 > Wrong
 >
 > Wrong

Kto-to majskij prazdnik otmechajet ;-)

BTW, here we call a bridge day "Fenstertag" (window day) and since we
didn't have any bridge day this week it _was_ the wrong day of the wrong
week indeed ...

I don't have any problems hard-coding `split-window-vertically' in
`dired-pop-to-buffer' but:

(1) `split-window-sensibly' with `split-width-threshold' nil _should_ do
     `split-window-vertically' in the first place.  If it doesn't, I have
     a bug somewhere and must fix that.

(2) Someone might want `split-window-sensibly' do something special for
     dired buffers.

So please try to debug this and tell me why it doesn't split the window
vertically with a dired-window-only-frame configuration in the first
attempt.  It DTRT here for me.

martin

PS: It does not DTRT when there's another window below because it does
not restore the original window layout when the temporary window is
closed.   But that's another story ...

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> Wrong
>>
>> Wrong
>
> Kto-to majskij prazdnik otmechajet ;-)
>
> BTW, here we call a bridge day "Fenstertag" (window day) and since we
> didn't have any bridge day this week it _was_ the wrong day of the wrong
> week indeed ...

:-)

> I don't have any problems hard-coding `split-window-vertically' in
> `dired-pop-to-buffer' but:
>
> (1) `split-window-sensibly' with `split-width-threshold' nil _should_ do
>     `split-window-vertically' in the first place.  If it doesn't, I have
>     a bug somewhere and must fix that.
>
> (2) Someone might want `split-window-sensibly' do something special for
>     dired buffers.
>
> So please try to debug this and tell me why it doesn't split the window
> vertically with a dired-window-only-frame configuration in the first
> attempt.  It DTRT here for me.

I tried to debug this.  With your latest patch it works correctly
with a dired-window-only-frame configuration, but fails when
there are two horizontally split side-by-side windows with a dired
buffer in one of them.  It displays a list of dired files at the top
of another side window.

split-window-sensibly has three `or' branches:

1. Split window vertically.

   In my case this branch is not selected because my window-height (79)
   is less than split-height-threshold (80).

2. Split window horizontally.

   This branch is not selected since dired-pop-to-buffer sets
   split-width-threshold to nil (this is ok).

3. If the selected window is the only window on its frame and is
   not the minibuffer window, try to split it vertically.

   This branch is not selected since the dired buffer's window is
   not the only window on its frame.

So display-buffer displays a list of dired files in the existing
side window.

I see one way to fix this - it is necessary to force
the first branch to be selected.  It works when I tried
the following lambda in dired-pop-to-buffer:

    (lambda ()
      (let ((split-height-threshold 0)
            (split-width-threshold nil))
        (with-selected-window old-window (funcall old-fun))))

Setting split-height-threshold to 0 forces the vertical splitting.
Setting split-width-threshold to nil prevents the horizontal splitting
when the vertical splitting is not possible (the window is not splittable).

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > 1. Split window vertically.
 >
 >    In my case this branch is not selected because my window-height (79)
 >    is less than split-height-threshold (80).

On my display this amounts to setting `split-height-threshold' nil.

 > So display-buffer displays a list of dired files in the existing
 > side window.
 >
 > I see one way to fix this - it is necessary to force
 > the first branch to be selected.  It works when I tried
 > the following lambda in dired-pop-to-buffer:
 >
 >     (lambda ()
 >       (let ((split-height-threshold 0)
 >             (split-width-threshold nil))
 >         (with-selected-window old-window (funcall old-fun))))
 >
 > Setting split-height-threshold to 0 forces the vertical splitting.
 > Setting split-width-threshold to nil prevents the horizontal splitting
 > when the vertical splitting is not possible (the window is not splittable).

You convinced me.

Thanks, martin.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

  >> `dired-pop-to-buffer' could bind `split-window-preferred-function' to a
  >> function that tries to always split the selected window instead of
  >> whatever window was chosen by `display-buffer' but that would override
  >> any user customizations of `split-window-preferred-function'.
  >
  > Why would it override it?  It would of course bind
  > split-window-preferred-function to a function that selects the right
  > window and then calls the previous value.

As a matter of fact, we do have to override the users' customizations
here just as Juri suggested earlier.  Suppose a user has set
`split-window-preferred-function' to the standard option "horizontally"
which always splits a window horizontally.  Then `dired-pop-to-buffer'
simply cannot get a vertical split when it calls the original
`split-window-preferred-function'.  So we probably have to do this as in
the attached patch :-(

martin


[-- Attachment #2: dired.el.diff --]
[-- Type: text/plain, Size: 1008 bytes --]

*** dired.el.~1.422.~	2009-04-18 08:32:56.546875000 +0200
--- dired.el	2009-05-05 09:00:38.609375000 +0200
***************
*** 2686,2693 ****
  
  (defun dired-pop-to-buffer (buf)
    "Pop up buffer BUF in a way suitable for Dired."
!   ;; Don't split window horizontally.  (Bug#1806)
!   (let (split-width-threshold)
      (pop-to-buffer (get-buffer-create buf)))
    ;; If dired-shrink-to-fit is t, make its window fit its contents.
    (when dired-shrink-to-fit
--- 2686,2697 ----
  
  (defun dired-pop-to-buffer (buf)
    "Pop up buffer BUF in a way suitable for Dired."
!   (let ((split-window-preferred-function
! 	 (lambda (window)
! 	   ;; Split window vertically and deliberately ignore the WINDOW
! 	   ;; argument of `split-window-preferred-function' so the
! 	   ;; selected window gets split instead (Bug#1806).
! 	   (split-window-vertically))))
      (pop-to-buffer (get-buffer-create buf)))
    ;; If dired-shrink-to-fit is t, make its window fit its contents.
    (when dired-shrink-to-fit

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> As a matter of fact, we do have to override the users' customizations
> here just as Juri suggested earlier.  Suppose a user has set
> `split-window-preferred-function' to the standard option "horizontally"
> which always splits a window horizontally.  Then `dired-pop-to-buffer'
> simply cannot get a vertical split when it calls the original
> `split-window-preferred-function'.

Thank you!  Could you also fix Proced and Calendar?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

 > Could you also fix Proced and Calendar?

I attached a similar patch for `proced-send-signal'.  I don't know what
to do about `proced' itself.  Roland what do you think?

martin

[-- Attachment #2: proced.el.diff --]
[-- Type: text/plain, Size: 1350 bytes --]

*** proced.el.~1.36.~	2009-04-21 07:18:50.000000000 +0200
--- proced.el	2009-05-18 10:01:50.031250000 +0200
***************
*** 1720,1728 ****
            (dolist (process process-alist)
              (insert "  " (cdr process) "\n"))
            (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)))
              (fit-window-to-buffer (get-buffer-window) nil 1)
              (let* ((completion-ignore-case t)
--- 1720,1735 ----
            (dolist (process process-alist)
              (insert "  " (cdr process) "\n"))
            (save-window-excursion
!             ;; Analogous to `dired-pop-to-buffer'.
! 	    (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-vertically))
! 			 ;; Otherwise, try to split WINDOW sensibly.
! 			 (split-window-sensibly window)))))
                (pop-to-buffer (current-buffer)))
              (fit-window-to-buffer (get-buffer-window) nil 1)
              (let* ((completion-ignore-case t)

bug#1806: dired-pop-to-buffer in wrong place

[Roland Winkler]

On Mon May 18 2009 martin rudalics wrote:
>  > Could you also fix Proced and Calendar?
> 
> I attached a similar patch for `proced-send-signal'.  I don't know what
> to do about `proced' itself.  Roland what do you think?

What do you mean by "proced itself"? Only proced-send-signal should
behave analogous to dired-pop-to-buffer.

Roland

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > What do you mean by "proced itself"? Only proced-send-signal should
 > behave analogous to dired-pop-to-buffer.

I meant whether `proced' which uses `pop-to-buffer' has any preferences
about where and how to pop up that buffer.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Roland Winkler]

On Mon May 18 2009 martin rudalics wrote:
> I meant whether `proced' which uses `pop-to-buffer' has any preferences
> about where and how to pop up that buffer.

I see. I have never much thought about that. If anyone has some
argument why it might be better that Proced used something else
instead of a simple call of pop-to-buffer, I'd be happy to use some
appropriate code. Otherwise I suggest to keep it the way it is now
(or wait till after the next release). Certainly, Proced is
different from Dired in the sense that normally one will have only
one such buffer.

Roland

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> I meant whether `proced' which uses `pop-to-buffer' has any preferences
>> about where and how to pop up that buffer.

> I see. I have never much thought about that. If anyone has some
> argument why it might be better that Proced used something else
> instead of a simple call of pop-to-buffer, I'd be happy to use some
> appropriate code. Otherwise I suggest to keep it the way it is now
> (or wait till after the next release). Certainly, Proced is
> different from Dired in the sense that normally one will have only
> one such buffer.

We should refrain from using anything else than just a plain
`pop-to-buffer', except for those cases where it is clearly problematic.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> I see. I have never much thought about that. If anyone has some
> argument why it might be better that Proced used something else
> instead of a simple call of pop-to-buffer, I'd be happy to use some
> appropriate code. Otherwise I suggest to keep it the way it is now
> (or wait till after the next release). Certainly, Proced is
> different from Dired in the sense that normally one will have only
> one such buffer.

Indeed, with its Dired-like keybindings it is still different from Dired
in regard to displaying a Proced window itself where it is more like
a Buffer List (`C-x C-b').  So e.g. as it's easy to add "*Buffer List*"
to `same-window-buffer-names', it's easy to add "*Proced*" as well
and to do other standard customizations allowed by `pop-to-buffer'.
This is unlike a non-standard treatment of displaying a window with
a list of selected items to process.  I think no change is needed
for `pop-to-buffer' that displays a Proced window.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

 > Could you also fix Proced and Calendar?

I suppose you mean the call in `calendar-basic-setup' here.  In this
case you probably want to split the largest or LRU window vertically
even if your customized settings would imply a horizontal split.  But
you don't insist on splitting the selected window.  Right?

Any opinions, Glenn?

martin

[-- Attachment #2: calendar.el.diff --]
[-- Type: text/plain, Size: 1108 bytes --]

*** calendar.el.~1.281.~	2009-03-16 07:35:28.000000000 +0100
--- calendar.el	2009-05-18 09:52:53.203125000 +0200
***************
*** 1291,1297 ****
      (calendar-increment-month month year (- calendar-offset))
      ;; Display the buffer before calling calendar-generate-window so that it
      ;; can get a chance to adjust the window sizes to the frame size.
!     (or nodisplay (pop-to-buffer calendar-buffer))
      (calendar-generate-window month year)
      (if (and calendar-view-diary-initially-flag
               (calendar-date-is-visible-p date))
--- 1291,1301 ----
      (calendar-increment-month month year (- calendar-offset))
      ;; Display the buffer before calling calendar-generate-window so that it
      ;; can get a chance to adjust the window sizes to the frame size.
!     (or nodisplay
! 	(let ((split-height-threshold 0)
! 	      split-width-threshold)
! 	  ;; Prefer vertical splits (Bug#1806).
! 	  (pop-to-buffer calendar-buffer)))
      (calendar-generate-window month year)
      (if (and calendar-view-diary-initially-flag
               (calendar-date-is-visible-p date))

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

martin rudalics wrote:

> I suppose you mean the call in `calendar-basic-setup' here.  In this
> case you probably want to split the largest or LRU window vertically
> even if your customized settings would imply a horizontal split.  But
> you don't insist on splitting the selected window.  Right?
>
> Any opinions, Glenn?

Hi; I haven't been following this, but after a quick skim of the
(long) thread, I think neither the current nor the proposed behaviour
is ideal (it seems to be a choice between getting the height wrong or
the width wrong), but I prefer the current one. I'd rather leave it as
is for now, and look to improve it after 23.1. Thanks.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> Hi; I haven't been following this, but after a quick skim of the
> (long) thread, I think neither the current nor the proposed behaviour
> is ideal (it seems to be a choice between getting the height wrong or
> the width wrong), but I prefer the current one. I'd rather leave it as
> is for now, and look to improve it after 23.1. Thanks.

It is unfortunate that no one yet paid attention to the Calendar's
treatment of the wide-screen configuration.  Since now we have
a new smart window splitting, it produces very bad results on such
configurations - `M-x calendar' displays an ugly 70-line window
instead of a narrow 7-line window that fits nicely to the contents
of the Calendar buffer.  That's because assumptions about the
behaviour of `display-buffer' in `calendar-basic-setup' and
`calendar-generate-window' are now invalid.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Glenn Morris wrote:

> Hi; I haven't been following this, but after a quick skim of the
> (long) thread, I think neither the current nor the proposed behaviour
> is ideal (it seems to be a choice between getting the height wrong or
> the width wrong), but I prefer the current one. I'd rather leave it as
> is for now, and look to improve it after 23.1.

I believe the behaviour of the calendar is now fixed in this regard.
I don't know if there is anything else left to do for this lengthy
bug, or if it can be closed now.

The only remaining calendar issue I can see is that one might prefer
the diary to always appear directly above (or below) the calendar,
rather than to one side. This could be achieved by the use of
windmove. I might install something along those lines, or I might not
bother.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> Hi; I haven't been following this, but after a quick skim of the
>> (long) thread, I think neither the current nor the proposed behaviour
>> is ideal (it seems to be a choice between getting the height wrong or
>> the width wrong), but I prefer the current one. I'd rather leave it as
>> is for now, and look to improve it after 23.1.
>
> I believe the behaviour of the calendar is now fixed in this regard.
> I don't know if there is anything else left to do for this lengthy
> bug, or if it can be closed now.

Thank you.  I wonder how did you test your change.  In emacs -Q
I see a strange window configuration after `M-x calendar RET'
in a single wide window:

    +-------------------------+        +------------+------------+
    |                         |        |            |            |
    |                         |        |            |            |
    |                         |        |            |            |
    |                         |        |            |            |
    |                         |        |            |            |
    |                         |        |            |            |
    |                         |  ===>  |            |            |
    |                         |        |            |            |
    |                         |        |            | *Messages* |
    |                         |        |            +------------+
    |                         |        |            |            |
    | *scratch*               |        | *scratch*  | *Calendar* |
    +-------------------------+        +------------+------------+

I believe it was supposed to do rather:

    +-------------------------+        +-------------------------+
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |  ===>  |                         |
    |                         |        |                         |
    |                         |        | *scratch*               |
    |                         |        +-------------------------+
    |                         |        |                         |
    | *scratch*               |        | *Calendar*              |
    +-------------------------+        +-------------------------+

i.e. the calendar to always appear directly below from the current window.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Stephen Berman]

On Tue, 06 Oct 2009 00:45:07 +0300 Juri Linkov <juri@jurta.org> wrote:

>>> Hi; I haven't been following this, but after a quick skim of the
>>> (long) thread, I think neither the current nor the proposed behaviour
>>> is ideal (it seems to be a choice between getting the height wrong or
>>> the width wrong), but I prefer the current one. I'd rather leave it as
>>> is for now, and look to improve it after 23.1.
>>
>> I believe the behaviour of the calendar is now fixed in this regard.
>> I don't know if there is anything else left to do for this lengthy
>> bug, or if it can be closed now.
>
> Thank you.  I wonder how did you test your change.  In emacs -Q
> I see a strange window configuration after `M-x calendar RET'
> in a single wide window:
>
>     +-------------------------+        +------------+------------+
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |  ===>  |            |            |
>     |                         |        |            |            |
>     |                         |        |            | *Messages* |
>     |                         |        |            +------------+
>     |                         |        |            |            |
>     | *scratch*               |        | *scratch*  | *Calendar* |
>     +-------------------------+        +------------+------------+
>
> I believe it was supposed to do rather:
>
>     +-------------------------+        +-------------------------+
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |  ===>  |                         |
>     |                         |        |                         |
>     |                         |        | *scratch*               |
>     |                         |        +-------------------------+
>     |                         |        |                         |
>     | *scratch*               |        | *Calendar*              |
>     +-------------------------+        +-------------------------+
>
> i.e. the calendar to always appear directly below from the current window.

I also see this.  What's more, I have things configured so that calling
Calendar also pops up the fancy diary display, and starting with a
single (screen-) wide window, the result is similar to the above, namely:

     +-------------------------+        +------------+------------+
     |                         |        |            |            |
     |                         |        |            |            |
     |                         |        |            |            |
     |                         |        |            |            |
     |                         |        |            |            |
     |                         |        |            |            |
     |                         |  ===>  |            |            |
     |                         |        |            |            |
     |                         |        |            | *Messages* |
     |                         |        |            +------------+
     |                         |        |            |            |
     | *scratch*               |        |    Diary   | *Calendar* |
     +-------------------------+        +------------+------------+

(Note that in the result *scratch* is not displayed in the frame, but
instead the previous buffer *Messages*.)

Steve Berman

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Stephen Berman wrote:

> What's more, I have things configured so that calling Calendar also
> pops up the fancy diary display, and starting with a single
> (screen-) wide window, the result is similar to the above, namely:
>
>      +-------------------------+        +------------+------------+
>      |                         |        |            |            |
>      |                         |        |            |            |
>      |                         |        |            |            |
>      |                         |        |            |            |
>      |                         |        |            |            |
>      |                         |        |            |            |
>      |                         |  ===>  |            |            |
>      |                         |        |            |            |
>      |                         |        |            | *Messages* |
>      |                         |        |            +------------+
>      |                         |        |            |            |
>      | *scratch*               |        |    Diary   | *Calendar* |
>      +-------------------------+        +------------+------------+

As I wrote:

   The only remaining calendar issue I can see is that one might
   prefer the diary to always appear directly above (or below) the
   calendar, rather than to one side. This could be achieved by the
   use of windmove. I might install something along those lines, or I
   might not bother.

bug#1806: dired-pop-to-buffer in wrong place

[Stephen Berman]

On Mon, 05 Oct 2009 22:53:02 -0400 Glenn Morris <rgm@gnu.org> wrote:

> Stephen Berman wrote:
>
>> What's more, I have things configured so that calling Calendar also
>> pops up the fancy diary display, and starting with a single
>> (screen-) wide window, the result is similar to the above, namely:
>>
>>      +-------------------------+        +------------+------------+
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |  ===>  |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            | *Messages* |
>>      |                         |        |            +------------+
>>      |                         |        |            |            |
>>      | *scratch*               |        |    Diary   | *Calendar* |
>>      +-------------------------+        +------------+------------+
>
> As I wrote:
>
>    The only remaining calendar issue I can see is that one might
>    prefer the diary to always appear directly above (or below) the
>    calendar, rather than to one side. This could be achieved by the
>    use of windmove. I might install something along those lines, or I
>    might not bother.

Oh yeah, sorry, I forgot about that.

Steve Berman

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> What's more, I have things configured so that calling Calendar also
>> pops up the fancy diary display, and starting with a single
>> (screen-) wide window, the result is similar to the above, namely:
>>
>>      +-------------------------+        +------------+------------+
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            |            |
>>      |                         |  ===>  |            |            |
>>      |                         |        |            |            |
>>      |                         |        |            | *Messages* |
>>      |                         |        |            +------------+
>>      |                         |        |            |            |
>>      | *scratch*               |        |    Diary   | *Calendar* |
>>      +-------------------------+        +------------+------------+
>
> As I wrote:
>
>    The only remaining calendar issue I can see is that one might
>    prefer the diary to always appear directly above (or below) the
>    calendar, rather than to one side. This could be achieved by the
>    use of windmove. I might install something along those lines, or I
>    might not bother.

I think the most expected way would be to display the calendar window
below the current buffer, and to display the diary above the calendar
(effectively what `d' does when invoked from the calendar) that replaces
the original buffer (*scratch* in this case) with the diary buffer:

    +-------------------------+        +-------------------------+
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |        |                         |
    |                         |  ===>  |                         |
    |                         |        |                         |
    |                         |        | *Diary*                 |
    |                         |        +-------------------------+
    |                         |        |                         |
    | *scratch*               |        | *Calendar*              |
    +-------------------------+        +-------------------------+

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Juri Linkov wrote:

> In emacs -Q I see a strange window configuration after `M-x calendar
> RET' in a single wide window:
>
>     +-------------------------+        +------------+------------+
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |        |            |            |
>     |                         |  ===>  |            |            |
>     |                         |        |            |            |
>     |                         |        |            | *Messages* |
>     |                         |        |            +------------+
>     |                         |        |            |            |
>     | *scratch*               |        | *scratch*  | *Calendar* |
>     +-------------------------+        +------------+------------+


That was the intended behaviour. If the frame is wide enough to split
horizontally, it is split horizontally. This both makes sense and
looks correct to me.

> I believe it was supposed to do rather:
>
>     +-------------------------+        +-------------------------+
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |        |                         |
>     |                         |  ===>  |                         |
>     |                         |        |                         |
>     |                         |        | *scratch*               |
>     |                         |        +-------------------------+
>     |                         |        |                         |
>     | *scratch*               |        | *Calendar*              |
>     +-------------------------+        +-------------------------+

It will do this if the frame is not wider than split-width-threshold.

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> +-------------------------+        +------------+------------+
>> |                         |        |            |            |
>> |                         |        |            |            |
>> |                         |        |            |            |
>> |                         |        |            |            |
>> |                         |        |            |            |
>> |                         |        |            |            |
>> |                         |  ===>  |            |            |
>> |                         |        |            |            |
>> |                         |        |            | *Messages* |
>> |                         |        |            +------------+
>> |                         |        |            |            |
>> | *scratch*               |        | *scratch*  | *Calendar* |
>> +-------------------------+        +------------+------------+

> That was the intended behaviour. If the frame is wide enough to split
> horizontally, it is split horizontally.  This both makes sense and
> looks correct to me.

Showing *Messages* out of the blue is definitely not a feature.
IOW It doesn't look correct to me.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Stefan Monnier wrote:

> Showing *Messages* out of the blue is definitely not a feature.
> IOW It doesn't look correct to me.

It's because:

-----------
| scratch |
|         |
|         |
-----------

goes to :

------------------
| scratch | other |
|         | ------
|         | cal   |
------------------

where `other' is whatever other-buffer returns. It's not choosing
messages specially, but obviously in emacs -Q there are no other
buffers available.

Then if you show the diary, it may happen to put it in the leftmost
window, replacing scratch.

AFAIK there are no general Emacs window-handling features to do any of
this in any more sophisticated fashion.

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Showing *Messages* out of the blue is definitely not a feature.
>> IOW It doesn't look correct to me.

> It's bécasse:
[..]
> AFAIK there are no general Emacs window-handling features to do any of
> this in any more sophisticated fashion.

I know why the code gives this result.  But still, result is not good.
I think it's better to end up with


   +----------------------------------------------------------+
   |                                                          |
   |                                                          |
   |                   *scratch*                              |
   |                                                          |
   +----------------------------------------------------------+
   |                                                          |
   |                                                          |
   |                   *calendar*                             |
   |                                                          |
   +----------------------------------------------------------+

It may be suboptimal, but at least it doesn't end up with a weird window
arrangement displaying some randomly chosen old buffer.  It's easy for
the user to hit C-x 3 before running calendar, if she doesn't like
this behavior; much easier than trying to fix the mess of the
current code, when you're not happy with its choices.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Stefan Monnier wrote:

> It may be suboptimal,

What is the optimal behaviour in your opinion?

> but at least it doesn't end up with a weird window arrangement
> displaying some randomly chosen old buffer.

The buffer is no longer randomly chosen. But now I see that Juri
objects to the result of that, sigh.

I don't agree that the window arrangement is "weird". I suppose if the
whole world continues to disagree with me, I will add
`calendar-split-width-threshold', default nil.

This whole exercise seems to have been a waste of time.

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> It may be suboptimal,
> What is the optimal behaviour in your opinion?

The optimal behavior depends on the user's intention, here.
Calendar can't know it.  So it should just strive to make it easy for
the user to get what she wants.

> This whole exercise seems to have been a waste of time.

Yes, I'm sorry about it, but clearly the new "automatic double split" is
not a good idea: sometimes it may correspond to what the user wanted,
but I expect it'll be rare, and as mentioned, it's a lot easy for those
users to hit C-x 3 before invoking calendar, than for the rest of them
to undo the damage.  KISS.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > It's because:
 >
 > -----------
 > | scratch |
 > |         |
 > |         |
 > -----------
 >
 > goes to :
 >
 > ------------------
 > | scratch | other |
 > |         | ------
 > |         | cal   |
 > ------------------
 >
 > where `other' is whatever other-buffer returns. It's not choosing
 > messages specially, but obviously in emacs -Q there are no other
 > buffers available.

It could show *scratch* twice.  Ideally, the "other" window would not be
created but a "vertical" calendar layout used instead ;-) Or show all
months of the respective year (maybe in some dimmed face) to make use of
the available space.  With the current layout I don't see much sense
doing a horizontal split at all.

 > Then if you show the diary, it may happen to put it in the leftmost
 > window, replacing scratch.
 >
 > AFAIK there are no general Emacs window-handling features to do any of
 > this in any more sophisticated fashion.

We could supply a command to show diary and cal simultaneously in two
windows above each other.  Otherwise, we could remember in a separate
variable which "other" window was created when the calendar window was
split off and, if that other window is still alive and the calendar
window is below or on the right of it, use it for displaying the diary.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

martin rudalics wrote:

> It could show *scratch* twice.

Yes, it could, easily.

> Ideally, the "other" window would not be created but a "vertical"
> calendar layout used instead ;-) Or show all months of the
> respective year (maybe in some dimmed face) to make use of the
> available space.

This is something I would like to see, but it is a lot of work.

> With the current layout I don't see much sense doing a horizontal
> split at all.

Because it makes zero sense to have a calendar wider than 80 columns.
The space is always wasted.

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> Because it makes zero sense to have a calendar wider than 80 columns.

But it doesn't harm either.

> The space is always wasted.

But it can be recovered by a simple C-x 2.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> It could show *scratch* twice.
>
> Yes, it could, easily.

Please don't duplicate buffers without users' consent.

>> Ideally, the "other" window would not be created but a "vertical"
>> calendar layout used instead ;-) Or show all months of the
>> respective year (maybe in some dimmed face) to make use of the
>> available space.
>
> This is something I would like to see, but it is a lot of work.

Yes, this would be ideal by either displaying the full year:

    +-------------------------+-------------------------+
    |                         | Jan2009 Feb2009 Mar2009 |
    |                         |                         |
    |                         |                         |
    |                         | Apr2009 May2009 Jun2009 |
    |                         |                         |
    |                         |                         |
    |                         | Jul2009 Aug2009 Sep2009 |
    |                         |                         |
    |                         |                         |
    |                         | Oct2009 Nov2009 Dec2009 |
    |                         |                         |
    | *scratch*               | *Calendar*              |
    +-------------------------+-------------------------+

or a long stripe for as much months will fit to the window's width:

    +---------------------------------------------------+
    |                                                   |
    |                                                   |
    |                                                   |
    |                                                   |
    |                                                   |
    |                                                   |
    |                                                   |
    | *scratch*                                         |
    +---------------------------------------------------+
    | May2009 Jun2009 Jul2009 Aug2009 Sep2009 Oct2009   |
    |                                                   |
    | *Calendar*                                        |
    +---------------------------------------------------+

I guess the latter would be easier to implement?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Juri Linkov wrote:

> Please don't duplicate buffers without users' consent.

So I can't win. They won't accept Messages (or whatever), you won't
accept another Scratch (or whatever).

> I guess the latter would be easier to implement?

No. Please let's not conflate these two separate issues.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

I noticed another case with weird behaviour.  Please confirm is this
intentional or not.  When initially a frame is split horizontally
in two side-by-side windows then after `M-x calendar' the calendar
appears not under the current window, but under another window
in the opposite pane, duplicating the buffer above it with the
initially current buffer (IOW, replacing *Messages* with *scratch*
in the following case):

    +------------+------------+        +------------+------------+
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |  ===>  |            |            |
    |            |            |        |            |            |
    | current    |            |        |            | *scratch*  |
    | buffer     |            |        |            +------------+
    |            |            |        |            |            |
    | *scratch*  | *Messages* |        | *scratch*  | *Calendar* |
    +------------+------------+        +------------+------------+

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

Juri Linkov wrote:

> I noticed another case with weird behaviour.  Please confirm is this
> intentional or not. 

Well, not so much intentional, as just, this is what pop-to-buffer
does. But, this is no longer the default behaviour - please try the
current CVS.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> I noticed another case with weird behaviour.  Please confirm is this
>> intentional or not.
>
> Well, not so much intentional, as just, this is what pop-to-buffer
> does. But, this is no longer the default behaviour - please try the
> current CVS.

Hmm, tried the current CVS and see no improvement.  I mean I still see
this default behaviour:

    +------------+------------+        +------------+------------+
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |  ===>  |            |            |
    |            |            |        |            |            |
    | current    |            |        |            | *scratch*  |
    | buffer     |            |        |            +------------+
    |            |            |        |            |            |
    | *scratch*  | *Messages* |        | *scratch*  | *Calendar* |
    +------------+------------+        +------------+------------+

I expected it to be rather:

    +------------+------------+        +------------+------------+
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |        |            |            |
    |            |            |  ===>  |            |            |
    |            |            |        |            |            |
    | current    |            |        | *scratch*  |            |
    | buffer     |            |        +------------+            |
    |            |            |        |            |            |
    | *scratch*  | *Messages* |        | *Calendar* | *Messages* |
    +------------+------------+        +------------+------------+

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>>> I noticed another case with weird behaviour.  Please confirm is this
>>> intentional or not.
>>
>> Well, not so much intentional, as just, this is what pop-to-buffer
>> does. But, this is no longer the default behaviour - please try the
>> current CVS.
>
> Hmm, tried the current CVS and see no improvement.  I mean I still see
> this default behaviour:

I think the problem is the lack of the necessary primitive in window.el.
Should it exist, any mode could use it with a simple function call
that creates a new window below the current one even in a wide-frame
configuration.  I remember Martin proposed a patch during the code freeze,
but currently can't find it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > I think the problem is the lack of the necessary primitive in window.el.
 > Should it exist, any mode could use it with a simple function call
 > that creates a new window below the current one even in a wide-frame
 > configuration.  I remember Martin proposed a patch during the code freeze,
 > but currently can't find it.

I'm currently rewriting the window code so this would be a good moment
to incorporate such wishlist items here.  Though for the present case
I'm not quite sure whether `pop-to-buffer' is the primitive you want: If
you want the new window definitely appear below the selected one, then
why not use `split-window' in the first place?  `pop-to-buffer' should
be allowed to use heuristics based on user preferences.  Applications
should not deliberatly override them.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> I think the problem is the lack of the necessary primitive in window.el.
>> Should it exist, any mode could use it with a simple function call
>> that creates a new window below the current one even in a wide-frame
>> configuration.  I remember Martin proposed a patch during the code freeze,
>> but currently can't find it.
>
> I'm currently rewriting the window code so this would be a good moment
> to incorporate such wishlist items here.  Though for the present case
> I'm not quite sure whether `pop-to-buffer' is the primitive you want: If
> you want the new window definitely appear below the selected one, then
> why not use `split-window' in the first place?  `pop-to-buffer' should
> be allowed to use heuristics based on user preferences.  Applications
> should not deliberatly override them.

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

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

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

Please don't use a new variable, but just extend
special-display-buffer-names.  It currently already accepts some special
parameters such as same-frame, so it could also handle new parameters
like `split-orientation' with values `side-by-side' or `top-down'.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Please don't use a new variable, but just extend
 > special-display-buffer-names.  It currently already accepts some special
 > parameters such as same-frame, so it could also handle new parameters
 > like `split-orientation' with values `side-by-side' or `top-down'.

`special-display-popup-frame' is a misnomer (and sits in the wrong file)
if we continue to overload it with such window specific enhancements.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Please don't use a new variable, but just extend
>> special-display-buffer-names.  It currently already accepts some special
>> parameters such as same-frame, so it could also handle new parameters
>> like `split-orientation' with values `side-by-side' or `top-down'.

> `special-display-popup-frame' is a misnomer (and sits in the wrong file)
> if we continue to overload it with such window specific enhancements.

Hmm... I did write special-display-buffer-names rather than
special-display-popup-frame, didn't I?


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> `special-display-popup-frame' is a misnomer (and sits in the wrong file)
 >> if we continue to overload it with such window specific enhancements.
 >
 > Hmm... I did write special-display-buffer-names rather than
 > special-display-popup-frame, didn't I?

Right.  But a match for `special-display-buffer-names' triggers the call
of `special-display-function' whose default value is
`special-display-popup-frame'.  And the latter has to handle all those
nasty things like 'same-window and 'same-frame, popping up a new frame
only as last resort.  That function has gone a long way ...

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>>> `special-display-popup-frame' is a misnomer (and sits in the wrong file)
>>> if we continue to overload it with such window specific enhancements.
>> Hmm... I did write special-display-buffer-names rather than
>> special-display-popup-frame, didn't I?
> Right.  But a match for `special-display-buffer-names' triggers the call
> of `special-display-function' whose default value is
> `special-display-popup-frame'.  And the latter has to handle all those
> nasty things like 'same-window and 'same-frame, popping up a new frame
> only as last resort.  That function has gone a long way ...

Oh, I see what you mean now.  Yes, it deserves a rename.  But that's
trivial to do, isn't it?


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Oh, I see what you mean now.  Yes, it deserves a rename.  But that's
 > trivial to do, isn't it?

Renaming the function is trivial.  The problem is finding meaningful
additional "frame-parameters" like 'same-window and 'same-frame and how
to make them interact with `pop-up-windows' and `pop-up-frames'.  I'm
afraid there are few people with non-nil `special-display-buffer-names'
already.  Making this more complicated won't help anyone.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Oh, I see what you mean now.  Yes, it deserves a rename.  But that's
>> trivial to do, isn't it?

> Renaming the function is trivial.  The problem is finding meaningful
> additional "frame-parameters" like 'same-window and 'same-frame

As mentioned in some past thread, `same-frame' and `same-window'
parameters were misdesigned (by yours truly).  It should probably be
a single parameter with values `same-frame' or `same-window' instead.
Then we'd want to add the values `near-minibuffer' or `contiguous' for
the dired-pop-to-buffer behavior.  For the split-orientation, I'm not
sure if that same parameter should be used, or if a new one should be
used instead.

> and how to make them interact with `pop-up-windows' and
> `pop-up-frames'.

I don't see much difficulty here.

> I'm afraid there are few people with non-nil
> `special-display-buffer-names' already.  Making this more complicated
> won't help anyone.

I don't follow.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> Renaming the function is trivial.  The problem is finding meaningful
 >> additional "frame-parameters" like 'same-window and 'same-frame
 >
 > As mentioned in some past thread, `same-frame' and `same-window'
 > parameters were misdesigned (by yours truly).  It should probably be
 > a single parameter with values `same-frame' or `same-window' instead.

IIRC all I did was replace "(same-buffer . t)" with "(same-window . t)"
when the buffer was supposed to be displayed in the "same" that is
"selected" window.  Using a term like "same-buffer" didn't strike me as
very intuitive and the term "same-window" was already used with similar
semantics in the "same-window-..." variables.  Moreover I tried to fix
the customization type of `special-display-buffer-names' which IIRC
didn't work before.  Is it that what you mean by "misdesign"?

Anyway, the "FRAME-PARAMETERS are pairs of the form (PARAMETER . VALUE)"
paradigm was present in Emacs 22 so I conjecture that any such misdesign
happened before I touched this ;-)

 > Then we'd want to add the values `near-minibuffer' or `contiguous' for
 > the dired-pop-to-buffer behavior.  For the split-orientation, I'm not
 > sure if that same parameter should be used, or if a new one should be
 > used instead.

I have no opinion about that because I don't use it.  But I'm afraid
that some confusion might result from the fact that "same-window" or
"near-minibuffer" could refer to the "window that shall be split" or to
the "window that shall be used" to display the buffer.

 >> and how to make them interact with `pop-up-windows' and
 >> `pop-up-frames'.
 >
 > I don't see much difficulty here.

I do.  `pop-up-windows' and `pop-up-frames' are user preferences that
should be observed.  The idea that applications can override them in
various ways - other-window > same-window > pop-up-windows is one of
these implicit priority chains `display-buffer' has to resolve - is
already not very helpful in this regard.  Giving an application even
more control wrt the behavior of `display-buffer' defeats the purpose of
customizing variables like `pop-up-windows'.

 >> I'm afraid there are few people with non-nil
 >> `special-display-buffer-names' already.  Making this more complicated
 >> won't help anyone.
 >
 > I don't follow.

I suppose the only person who ever sets `special-display-buffer-names'
to a non-nil value is you.  Application programmers OTOH got used to
sweeping blows like

   (let ((special-display-buffer-names nil)
	(special-display-regexps nil)
	(same-window-buffer-names nil)
	(same-window-regexps nil))
     (pop-to-buffer ...

in order to redeem any complications caused by these variables.

So if we want users to customize these variables and at the same time
application programmers respect users' settings we should rather try to
simplify things instead of introducing further dependencies (IMHO).

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> As mentioned in some past thread, `same-frame' and `same-window'
>> parameters were misdesigned (by yours truly).  It should probably be
>> a single parameter with values `same-frame' or `same-window' instead.
[ "yours truly" means something like "myself" rather than "you". ]
[...]
> Anyway, the "FRAME-PARAMETERS are pairs of the form (PARAMETER . VALUE)"
> paradigm was present in Emacs 22 so I conjecture that any such misdesign
> happened before I touched this ;-)

The problem is that `same-frame' should not be a PARAMETER but a VALUE.
That was the original misdesign.

>> Then we'd want to add the values `near-minibuffer' or `contiguous' for
>> the dired-pop-to-buffer behavior.  For the split-orientation, I'm not
>> sure if that same parameter should be used, or if a new one should be
>> used instead.

> I have no opinion about that because I don't use it.  But I'm afraid
> that some confusion might result from the fact that "same-window" or
> "near-minibuffer" could refer to the "window that shall be split" or to
> the "window that shall be used" to display the buffer.

There are indeed two questions here:
1- in which area of which frame should the buffer be created.
2- should display-buffer create a new window for it, or should it use
   an existing window.
Maybe these two issues are really orthogonal so they deserve
separate PARAMETERS.  I.e. one parameter about *where* to display the
buffer (same-frame, same-window, near-minibuffer, nearby, ...), and the
other about how to display it (reuse-window, create-new-window, or
create-new-frame).

>>> and how to make them interact with `pop-up-windows' and
>>> `pop-up-frames'.
>> I don't see much difficulty here.
> I do.  `pop-up-windows' and `pop-up-frames' are user preferences that
> should be observed.  The idea that applications can override them in
> various ways - other-window > same-window > pop-up-windows is one of
> these implicit priority chains `display-buffer' has to resolve - is
> already not very helpful in this regard.  Giving an application even
> more control wrt the behavior of `display-buffer' defeats the purpose of
> customizing variables like `pop-up-windows'.

The intention of those changes is to let more applications use
display-buffer rather than hand-crafted combinations of split-window,
switch-to-buffer and things like that, so it should only give more
control to the user, not the opposite.

> I suppose the only person who ever sets `special-display-buffer-names'
> to a non-nil value is you.

Could be, but I doubt it.

> Application programmers OTOH got used to
> sweeping blows like

>   (let ((special-display-buffer-names nil)
> 	(special-display-regexps nil)
> 	(same-window-buffer-names nil)
> 	(same-window-regexps nil))
>     (pop-to-buffer ...

> in order to redeem any complications caused by these variables.

Yes, such programming should be fixed.  Fixing requires making it
possible for the application to say what it wants in some other way
(more precise) than by rebinding those vars.  Things like `same-window'
is precisely designed for such uses.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > [ "yours truly" means something like "myself" rather than "you". ]

I must be suffering from a persecution complex.

 > There are indeed two questions here:
 > 1- in which area of which frame should the buffer be created.
 > 2- should display-buffer create a new window for it, or should it use
 >    an existing window.
 > Maybe these two issues are really orthogonal so they deserve
 > separate PARAMETERS.  I.e. one parameter about *where* to display the
 > buffer (same-frame, same-window, near-minibuffer, nearby, ...), and the
 > other about how to display it (reuse-window, create-new-window, or
 > create-new-frame).

That's what I meant.  Currently these issues are conflated.

 > Yes, such programming should be fixed.  Fixing requires making it
 > possible for the application to say what it wants in some other way
 > (more precise) than by rebinding those vars.  Things like `same-window'
 > is precisely designed for such uses.

I suppose you mean 'same-window as possible value of NOT-THIS-WINDOW
here.  Overriding the values of customized variables is problematic.
Consider the (let ((window-min-height 1)) paradigm to make a one-line
window.  This is, inherently, disastrous because it implicitly lets the
window that shall be split shrink to one line while the binding is
effective although the clear intention of the programmer is to make this
affect only the window that shall be created.

I think that an application should never bind any variable guarding the
windows popup and resizing behavior.  For `display-buffer' this means
that the entire necessary information should be passed via the
NOT-THIS-WINDOW and FRAME arguments.  For `split-window' I suppose an
explicit size argument should allow to set the size of the respective
(old or new) window disregarding the actual `window-min-height' settings
and honor these settings for all other windows.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> Yes, such programming should be fixed.  Fixing requires making it
>> possible for the application to say what it wants in some other way
>> (more precise) than by rebinding those vars.  Things like `same-window'
>> is precisely designed for such uses.

> I suppose you mean 'same-window as possible value of NOT-THIS-WINDOW
> here.  Overriding the values of customized variables is problematic.

It would not override settings in special-display-buffer-names.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >>> Yes, such programming should be fixed.  Fixing requires making it
 >>> possible for the application to say what it wants in some other way
 >>> (more precise) than by rebinding those vars.  Things like `same-window'
 >>> is precisely designed for such uses.
 >
 >> I suppose you mean 'same-window as possible value of NOT-THIS-WINDOW
 >> here.  Overriding the values of customized variables is problematic.
 >
 > It would not override settings in special-display-buffer-names.

I just wanted to make sure that with "Things like `same-window'" you do
not intend a (same-window . t) entry in `special-display-buffer-names'.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> It would not override settings in special-display-buffer-names.
> I just wanted to make sure that with "Things like `same-window'" you do
> not intend a (same-window . t) entry in `special-display-buffer-names'.

The way I see it, the `other-window' argument to pop-to-buffer should be
able to provide such settings as well.  I.e. they could be provided both
by the user in s-d-b-n and by the code in other-window.  And of course,
application-provided settings would only take precedence over global
settings and not over user cutomizations.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >>> It would not override settings in special-display-buffer-names.
 >> I just wanted to make sure that with "Things like `same-window'" you do
 >> not intend a (same-window . t) entry in `special-display-buffer-names'.
 >
 > The way I see it, the `other-window' argument to pop-to-buffer should be
 > able to provide such settings as well.  I.e. they could be provided both
 > by the user in s-d-b-n and by the code in other-window.  And of course,
 > application-provided settings would only take precedence over global
 > settings and not over user cutomizations.

Currently, OTHER-WINDOW non-nil is an application-provided setting and
takes precedence over user customizations.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>>> I just wanted to make sure that with "Things like `same-window'" you do
>>> not intend a (same-window . t) entry in `special-display-buffer-names'.
>> The way I see it, the `other-window' argument to pop-to-buffer should be
>> able to provide such settings as well.  I.e. they could be provided both
>> by the user in s-d-b-n and by the code in other-window.  And of course,
>> application-provided settings would only take precedence over global
>> settings and not over user cutomizations.
> Currently, OTHER-WINDOW non-nil is an application-provided setting

Right, and it will stay this way.

> and takes precedence over user customizations.

We would want to change that, then.

Note that the only customization it can override is the `same-window'
one IIUC, which is pretty new, so it currently only overrides user
customizations in very rare cases and I'm not sure that it's a feature
rather than a bug.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> Currently, OTHER-WINDOW non-nil is an application-provided setting
 >
 > Right, and it will stay this way.
 >
 >> and takes precedence over user customizations.
 >
 > We would want to change that, then.
 >
 > Note that the only customization it can override is the `same-window'
 > one IIUC, which is pretty new, so it currently only overrides user
 > customizations in very rare cases and I'm not sure that it's a feature
 > rather than a bug.

Should `switch-to-buffer-other-window' then be allowed to display the
buffer in the same window?  The Elisp manual would certainly forbid such
behavior:

      The currently selected window is absolutely never used to do the
      job.  If it is the only window, then it is split to make a
      distinct window for this purpose.  If the selected window is
      already displaying the buffer, then it continues to do so, but
      another window is nonetheless found to display it in as well.

And the OTHER-WINDOW argument was invented precisely to handle
`switch-to-buffer-other-window' via `display-buffer', IIUC.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>>>>> "martin" == martin rudalics <rudalics@gmx.at> writes:

>>> Currently, OTHER-WINDOW non-nil is an application-provided setting
>> 
>> Right, and it will stay this way.
>> 
>>> and takes precedence over user customizations.
>> 
>> We would want to change that, then.
>> 
>> Note that the only customization it can override is the `same-window'
>> one IIUC, which is pretty new, so it currently only overrides user
>> customizations in very rare cases and I'm not sure that it's a feature
>> rather than a bug.

> Should `switch-to-buffer-other-window' then be allowed to display the
> buffer in the same window?  The Elisp manual would certainly forbid such
> behavior:

>      The currently selected window is absolutely never used to do the
>      job.  If it is the only window, then it is split to make a
>      distinct window for this purpose.  If the selected window is
>      already displaying the buffer, then it continues to do so, but
>      another window is nonetheless found to display it in as well.

> And the OTHER-WINDOW argument was invented precisely to handle
> `switch-to-buffer-other-window' via `display-buffer', IIUC.

I guess that depends on why switch-to-buffer-other-window uses
pop-to-buffer.

Note that the use of pop-to-buffer already causes the curent behavior to
be different from the doc you cite: with pop-up-frames set to non-nil,
if the currently selected window is the only window, it is not split:
another frame is creqated instead.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > I guess that depends on why switch-to-buffer-other-window uses
 > pop-to-buffer.

Because it was convenient that way - before 1985 just as now.

 > Note that the use of pop-to-buffer already causes the curent behavior to
 > be different from the doc you cite: with pop-up-frames set to non-nil,
 > if the currently selected window is the only window, it is not split:
 > another frame is creqated instead.

Indeed.  But my point remains that I'm not sure whether switching from
`switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer'
and not using the selected window in the former (or using the selected
window in the latter) case might cause indignations of users.  Also so
because the `switch-to...' functions are frequently used by Elisp code.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> I guess that depends on why switch-to-buffer-other-window uses
>> pop-to-buffer.
> Because it was convenient that way - before 1985 just as now.

Than the right fix might be to change switch-to-buffer-other-window to
not use pop-to-buffer or to use it in an even more awkward way (binding
special-display-buffer-names to nil arounf the call and things like
that).

> Indeed.  But my point remains that I'm not sure whether switching from
> `switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer'
> and not using the selected window in the former (or using the selected
> window in the latter) case might cause indignations of users.

I'm not sure I understand.  We're talking about changing display-buffer
and pop-to-buffer, not switch-to-buffer (and hopefully not
switch-to-buffer-other-window, tho it may end up being affected
somewhat).

> Also so because the `switch-to...' functions are frequently used by
> Elisp code.

It's a concern but not a very serious one: I already consider such uses
as problems to be fixed.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Than the right fix might be to change switch-to-buffer-other-window to
 > not use pop-to-buffer or to use it in an even more awkward way (binding
 > special-display-buffer-names to nil arounf the call and things like
 > that).

IIUC the OTHER-WINDOW argument of `pop-to-buffer' was introduced to
allow `switch-to-buffer-other-window/-frame' use `pop-to-buffer'.  Not
using `pop-to-buffer' would mean we'd have to duplicate most of the code
of `display-buffer' omitting only the parts that deal with the
`same-window-...' and `special-display-...' variables.

So I think it would be easier to have `switch-to-buffer-other-window'
pass the constant 'other-window to `display-buffer' and handle that case
specially there.  In principle this means that we'd have to ignore the
`same-window-...' variables and make sure that
`special-display-function' does not return the same window.
`switch-to-buffer-other-frame' then would have to pass 'other-frame to
`display-buffer' and be handled in a similar manner.

 >> Indeed.  But my point remains that I'm not sure whether switching from
 >> `switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer'
 >> and not using the selected window in the former (or using the selected
 >> window in the latter) case might cause indignations of users.
 >
 > I'm not sure I understand.  We're talking about changing display-buffer
 > and pop-to-buffer, not switch-to-buffer (and hopefully not
 > switch-to-buffer-other-window, tho it may end up being affected
 > somewhat).

What I meant is that when we have `display-buffer' not let the
NOT-THIS-WINDOW argument override user customizations we'd change the
semantics of `switch-to-buffer-other-window/-frame'.  I suppose we can't
end up having these display the buffer in the same window so we somehow
have to make sure that the NOT-THIS-WINDOW/OTHER-WINDOW argument is
handled specially for these functions (if they use `display-buffer').

 >> Also so because the `switch-to...' functions are frequently used by
 >> Elisp code.
 >
 > It's a concern but not a very serious one: I already consider such uses
 > as problems to be fixed.

Well, there's lots of them :-(

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> IIUC the OTHER-WINDOW argument of `pop-to-buffer' was introduced to
> allow `switch-to-buffer-other-window/-frame' use `pop-to-buffer'.

I understand.  But I also pointed out some changes in semantics (in
switch-to-buffer-other-window) that resulted from this choice that might
not have been wanted.

> So I think it would be easier to have `switch-to-buffer-other-window'
> pass the constant 'other-window to `display-buffer' and handle that
> case specially there.  In principle this means that we'd have to
> ignore the `same-window-...' variables and make sure that
> `special-display-function' does not return the same window.
> `switch-to-buffer-other-frame' then would have to pass 'other-frame to
> `display-buffer' and be handled in a similar manner.

Maybe that would be a way to go.  In any case my suggestion to extend
the `other-window' arg to allow other specifications such as
same-window, same-frame, etc... was not meant to replace the current
functionality but to add some, so that more code can say what it means
rather than having to hack around (e.g. using switch-to-buffer where all
it really means is "use the current-window if possible and not specified
otherwise by the user").

>> It's a concern but not a very serious one: I already consider such uses
>> as problems to be fixed.
> Well, there's lots of them :-(

Not all of them are important, luckily,


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

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

So what I really need to know is how you (1) expect this to work
ideally, and (2) how to proceed when (1) fails.

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.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

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

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

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

`dired-pop-to-buffer' explicitly specifies that it wants to split the
selected window.  Your defcustom does not specifiy _which_ window to
split.

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

For that purpose we would have to specify (1) which window should be
split preferably and (2) how to split that window.

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

I agree.  We're in a lose-lose situation here.  Popping up a separate
frame would be probably better here.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

martin rudalics wrote:

>>> 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.
>
> I agree.  We're in a lose-lose situation here.  Popping up a separate
> frame would be probably better here.

Once again: this is no longer the default behaviour.

I think this bug is now far too long and complex to understand.
I suggest starting a new one with a summary of the outstanding issues.
(not volunteering)

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

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

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

martin rudalics wrote:

> We could supply a command to show diary and cal simultaneously in two
> windows above each other.

(setq calendar-setup 'one-frame)

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> We could supply a command to show diary and cal simultaneously in two
>> windows above each other.
>
> (setq calendar-setup 'one-frame)

Exactly.  When `calendar-setup' is configured to display the calendar
in a separate frame and the frame is wide, we don't try filling the
available space with random buffers.  A single-frame configuration
should not be different from this.

A wide-screen single-frame configuration is a special case.  At least,
I perceive `C-x 3' as a way to create a virtual two-frame configuration
with two side-by-side frame-like windows.  Consequently, I expect
`M-x calendar' respecting my choice: either keeping the single frame
and displaying the calendar below the current buffer, or when I create
a virtual two-frame configuration with `C-x 3' then keeping this
configuration intact and displaying the calendar below the current buffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> Could you also fix Proced and Calendar?
>
> I suppose you mean the call in `calendar-basic-setup' here.  In this
> case you probably want to split the largest or LRU window vertically
> even if your customized settings would imply a horizontal split.  But
> you don't insist on splitting the selected window.  Right?

It seems a fix is not as simple.  The function `calendar-generate-window'
comes into play and doesn't adjust the window to fit the displayed calendar
in horizontally split windows.  The condition (not (window-full-width-p))
prevents calling `fit-window-to-buffer':

      (if (or (one-window-p t) (not (window-full-width-p)))
          ;; Don't mess with the window size, but ensure that the first
          ;; line is fully visible.
          (set-window-vscroll nil 0)
        ;; Adjust the window to exactly fit the displayed calendar.
        (fit-window-to-buffer nil nil calendar-minimum-window-height))

Removing (not (window-full-width-p)) fixes this, but I don't know if this
change has some side effect.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>       (if (or (one-window-p t) (not (window-full-width-p)))
>           ;; Don't mess with the window size, but ensure that the first
>           ;; line is fully visible.
>           (set-window-vscroll nil 0)
>         ;; Adjust the window to exactly fit the displayed calendar.
>         (fit-window-to-buffer nil nil calendar-minimum-window-height))

> Removing (not (window-full-width-p)) fixes this, but I don't know if this
> change has some side effect.

Often (not (window-full-width-p)) is used as a round-about and confusing
way to check whether resizing is safe (in the sense that it doesn't
risk deleting other windows along the way).  In such cases, it is
preferable to use window-safely-shrinkable-p, which is also
less conservative.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> And that's good: the list should be close to the question, not close to
>> the dired buffer.
>
> If the dired buffer were not needed while asking the question, dired
> could temporarily display that list in the dired window itself and
> switch back to the dired buffer afterwards.  But I never use dired.

Actually Dired already displays that list in the Dired window itself
when the list is too large and fills the whole window.  But it would be
bad to replace the Dired buffer with a small list with 2-3 filename lines
and a lot of empty lines.  So it is better to display a separate window
near the minibuffer without empty lines using `fit-window-to-buffer'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Actually Dired already displays that list in the Dired window itself
 > when the list is too large and fills the whole window.  But it would be
 > bad to replace the Dired buffer with a small list with 2-3 filename lines
 > and a lot of empty lines.  So it is better to display a separate window
 > near the minibuffer without empty lines using `fit-window-to-buffer'.

Reasonable.  I suppose we should try to stay in the same "column" when
frames are divided horizontally.  Any fallback we should use when a
bottom window can't be split?  Split the selected one?

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> Actually Dired already displays that list in the Dired window itself
>> when the list is too large and fills the whole window.  But it would be
>> bad to replace the Dired buffer with a small list with 2-3 filename lines
>> and a lot of empty lines.  So it is better to display a separate window
>> near the minibuffer without empty lines using `fit-window-to-buffer'.
>
> Reasonable.  I suppose we should try to stay in the same "column" when
> frames are divided horizontally.  Any fallback we should use when a
> bottom window can't be split?  Split the selected one?

Creating a full-width window would fit more information, and the
window width will be the same as the width of the minibuffer's window.
This will more logically connect a new window to the minibuffer
that is necessary for dired files and completions:

    +------------+------------+
    |            |            |
    |            |            |
    |   dired    |   other    |
    |            |            |
    |            |            |
    +------------+            |
    |   other    |            |
    |            |            |
    +------------+------------+
    | file1.ext file2.ext     |
    | file3.ext file4.ext     |
    +-------------------------+
    | Prompt: command         |
    +-------------------------+

I think this would be the best layout, but not sure is it possible
to create it using splitting from the initial configuration?

    +------------+------------+
    |            |            |
    |            |            |
    |   dired    |   other    |
    |            |            |
    |            |            |
    +------------+            |
    |   other    |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    +------------+------------+
    | Prompt: command         |
    +-------------------------+

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >     +------------+------------+
 >     |            |            |
 >     |            |            |
 >     |   dired    |   other    |
 >     |            |            |
 >     |            |            |
 >     +------------+            |
 >     |   other    |            |
 >     |            |            |
 >     +------------+------------+
 >     | file1.ext file2.ext     |
 >     | file3.ext file4.ext     |
 >     +-------------------------+
 >     | Prompt: command         |
 >     +-------------------------+
 >
 > I think this would be the best layout, but not sure is it possible
 > to create it using splitting from the initial configuration?

Not really.  Creating windows anew breaks the 'window property of
overlays.  ISTR that Lennart has some code to fix that, but the overhead
may be considerable since you have to investigate all overlays and most
of them usually don't have the 'window property.  Here I simply split
the root window to get the effect you mean.  In any case, restoring the
previous configuration when the window is no more needed is not entirely
trivial either.

I suppose, for the moment we have to split the "other" window below
instead.  That is, check if there is a window with the same left edge as
the dired window and the maximum bottom edge of all windows on this
frame.  If that window cannot be split because it's too small or fixed
height, try to split the selected window (the dired window) instead.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> Maybe we
>> should have a special function to display a buffer above the minibuffer
>> (e.g. `pop-to-buffer-above-minibuffer')?
>
> But when you have vertically-split windows and the *dired* buffer
> appears on top of the frame, there may be another window between the
> *dired* window and the *Marked files* window.

The list of files closer to the minibuffer is better than closer to the
dired buffer because the minibuffer is the place that the user looks at
while typing command's arguments for these files.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > The list of files closer to the minibuffer is better than closer to the
 > dired buffer because the minibuffer is the place that the user looks at
 > while typing command's arguments for these files.

Unless our user uses a separate minibuffer-only frame.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> The list of files closer to the minibuffer is better than closer to the
>> dired buffer because the minibuffer is the place that the user looks at
>> while typing command's arguments for these files.
> Unless our user uses a separate minibuffer-only frame.

In that case the right behavior depends on many things (e.g. depends on
where the minibuffer frame is located w.r.t to selected frame).  To get
this right most of time will require a lot of heuristic code, so we may
as well punt on it and decide that any behavior that's OK for
non-minibuffer-only situations is OK for minibuffer-only situations
as well.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > I think pop-to-buffer should be extended in the following way:
 > currently, the only way for pop-to-buffer to indicate "where" to display
 > the buffer is via the `other-buffer' argument.

... you mean the `other-window' argument ...

 > This should be
 > generalized so as to be able to say "preferably in the selected-window"
 > (to provide basically the behavior of switch-to-buffer), or "preferably
 > in selected-frame", or "preferably close to the minibuffer".  The first
 > 2 are available *to the user* via the `same-window' and `same-frame'
 > attribute that they can set in special-display-buffer-names, but they
 > should also be available to the program (and overridable by the user).

But none of these provide the behavior wanted by Juri.  He wants to
split the selected window which runs counter to the `pop-up-frames'
non-nil ideology.  So I suppose we need a "preferably splitting the
selected window" value which can be overridden by `pop-up-frames'.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> This should be
>> generalized so as to be able to say "preferably in the selected-window"
>> (to provide basically the behavior of switch-to-buffer), or "preferably
>> in selected-frame", or "preferably close to the minibuffer".  The first
>> 2 are available *to the user* via the `same-window' and `same-frame'
>> attribute that they can set in special-display-buffer-names, but they
>> should also be available to the program (and overridable by the user).
>
> But none of these provide the behavior wanted by Juri.  He wants to
> split the selected window which runs counter to the `pop-up-frames'
> non-nil ideology.  So I suppose we need a "preferably splitting the
> selected window" value which can be overridden by `pop-up-frames'.

The preferred location of the window can be expressed by the new parameter
proposed by Stefan: in addition to `same-window' and `same-frame' it
could also support a parameter like `fit-below' with the meaning
of creating a new window below from the current window with calling
`fit-window-to-buffer' on it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> But none of these provide the behavior wanted by Juri.  He wants to
 >> split the selected window which runs counter to the `pop-up-frames'
 >> non-nil ideology.
 >
 > `same-frame' provides some of the behavior he wants.  If the user who
 > sets pop-up-frames is disappointed that it doesn't bring up a frame, she
 > can set her special-display-buffer-name so as to override that
 > `same-frame' attribute.

That's not what I meant.  The old `dired-pop-to-buffer' did split the
window regardless of what `pop-up-frames' was set to and Juri wants to
get the old behavior back.  The question is whether we want
`pop-up-frames' non-nil override that.  Currently, `pop-up-frames'
non-nil does bring up a separate frame.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>>> But none of these provide the behavior wanted by Juri.  He wants to
>>> split the selected window which runs counter to the `pop-up-frames'
>>> non-nil ideology.
>> `same-frame' provides some of the behavior he wants.  If the user who
>> sets pop-up-frames is disappointed that it doesn't bring up a frame, she
>> can set her special-display-buffer-name so as to override that
>> `same-frame' attribute.
> That's not what I meant.  The old `dired-pop-to-buffer' did split the
> window regardless of what `pop-up-frames' was set to and Juri wants to
> get the old behavior back.  The question is whether we want
> `pop-up-frames' non-nil override that.  Currently, `pop-up-frames'
> non-nil does bring up a separate frame.

I think either behavior is acceptable as long as it can be overridden by
the user (via special-display-buffer-names).  Reproducing the previous
behavior (of ignoring pop-up-frames) is probably the safer option, and
it at least would suit my use-pattern better as well (I do have
pop-up-frames set to t but would rather not have a new frame created for
those dired-lists unless I explicitly set one up in
special-display-buffer-names with a specific geometry).


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > I think either behavior is acceptable as long as it can be overridden by
 > the user (via special-display-buffer-names).  Reproducing the previous
 > behavior (of ignoring pop-up-frames) is probably the safer option, and
 > it at least would suit my use-pattern better as well (I do have
 > pop-up-frames set to t but would rather not have a new frame created for
 > those dired-lists unless I explicitly set one up in
 > special-display-buffer-names with a specific geometry).

Maybe we should have `special-display-popup-frame' handle yet another
phony parameter, say 'split-window, making it split the selected window
if that is set.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

>> I think either behavior is acceptable as long as it can be overridden by
>> the user (via special-display-buffer-names).  Reproducing the previous
>> behavior (of ignoring pop-up-frames) is probably the safer option, and
>> it at least would suit my use-pattern better as well (I do have
>> pop-up-frames set to t but would rather not have a new frame created for
>> those dired-lists unless I explicitly set one up in
>> special-display-buffer-names with a specific geometry).

> Maybe we should have `special-display-popup-frame' handle yet another
> phony parameter, say 'split-window, making it split the selected window
> if that is set.

Not sure if `split-window' is really what we want.  I thought in this
case, we want `near-minibuffer'.  But, yes, I basically agree.

Note that the parameter should be passed from the code, not from
special-display-buffer-names (which is a config variable).


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Glenn Morris]

This bug is massive, unchanged for two years, and predates the Great
Window-Handling Change. I cannot follow what the actual "bug" is here;
it seems to have just turned into an extended general discussion.

I don't think it is useful to keep this open, so I propose to close
this, and ask people to open new bugs focused on whatever specific,
individual issues remain.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> This bug is massive, unchanged for two years, and predates the Great
> Window-Handling Change. I cannot follow what the actual "bug" is here;
> it seems to have just turned into an extended general discussion.
>
> I don't think it is useful to keep this open, so I propose to close
> this, and ask people to open new bugs focused on whatever specific,
> individual issues remain.

Actually after Martin introduced a new variable `window-nest' it's
possible now to fix this bug in `dired-pop-to-buffer' where window space
for the *Marked Files* buffer is stolen from the wrong window in the
following configuration:

          ______________________________________
         | ____________________________________ |
         ||                                    ||
         ||                                    ||
         ||                                    ||
         ||                                    ||
         ||                                    ||
         ||                                    ||
         ||_________________W2_________________||
         | ____________________________________ |
         ||                                    ||
         ||                                    ||
         ||_________________W3_________________||
         |__________________W1__________________|

with the following simple patch:

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2011-09-18 20:43:20 +0000
+++ lisp/dired.el	2011-10-04 23:55:18 +0000
@@ -2873,7 +2873,8 @@ (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
+  (let* ((window-nest t)
+	 (split-window-preferred-function
 	 (lambda (window)
 	   (or (and (let ((split-height-threshold 0))
 		      (window-splittable-p (selected-window)))



After fixing it this bug could be closed, and other possibilities
(e.g. to display this buffer above the minibuffer etc.) could be postponed
to 24.2 and discussed in a new feature request.

bug#1806: dired-pop-to-buffer in wrong place

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Actually after Martin introduced a new variable `window-nest' it's
> possible now to fix this bug in `dired-pop-to-buffer' where window space
> for the *Marked Files* buffer is stolen from the wrong window in the
> following configuration:
>
>           ______________________________________
>          | ____________________________________ |
>          ||                                    ||
>          ||                                    ||
>          ||_________________W2_________________||
>          | ____________________________________ |
>          ||                                    ||
>          ||_________________W3_________________||
>          |__________________W1__________________|
>

I assume W2 is showing the Dired buffer in this example?  If so, the
proposed patch has no effect---W2 is split, so W3 is between the *Marked
Files* buffer and the echo area.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> I assume W2 is showing the Dired buffer in this example?

Yes, W2 is showing the Dired buffer.  This is a clearer picture:

          ______________________________________
         | ____________________________________ |
         ||                                    ||
         ||                                    ||
         ||               Dired                ||
         ||                                    ||
         ||_________________W2_________________||
         | ____________________________________ |
         ||                                    ||
         ||_________________W3_________________||
         |__________________W1__________________|

> If so, the proposed patch has no effect---W2 is split, so W3 is
> between the *Marked Files* buffer and the echo area.

The problem is that currently `fit-window-to-buffer' in
`dired-pop-to-buffer' increases the height of the unrelated window W3
like is shown below:

          ______________________________________
         | ____________________________________ |
         ||               Dired                ||
         ||_________________W2_________________||
         | ____________________________________ |
         ||            *Marked Files*          ||
         ||_________________W4_________________||
         | ____________________________________ |
         ||                                    ||
         ||                                    ||
         ||                                    ||
         ||                                    ||
         ||_________________W3_________________||
         |__________________W1__________________|

This is very ugly.

But when the *Marked Files* window is created when `window-nest' is t, then
`fit-window-to-buffer' doesn't enlarge the unrelated window W3 since
a new internal window W5 forces it to resize the Dired window W2:

          ______________________________________
         | ____________________________________ |
         || __________________________________ ||
         |||                                  |||
         |||              Dired               |||
         |||________________W2________________|||
         || __________________________________ ||
         |||           *Marked Files*         |||
         |||________________W4________________|||
         ||_________________W5_________________||
         | ____________________________________ |
         ||                                    ||
         ||_________________W3_________________||
         |__________________W1__________________|

Unless there is a way to tell `fit-window-to-buffer' to change the height
of the upper window instead of the lower window, setting `window-nest' to t
can fix `dired-pop-to-buffer' to not resize other unrelated windows.

bug#1806: dired-pop-to-buffer in wrong place

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> The problem is that currently `fit-window-to-buffer' in
> `dired-pop-to-buffer' increases the height of the unrelated window W3
>
> This is very ugly.

OK, but (i) this seems unrelated to the issue you originally raised in
this bug, and (ii) surely this is not special to Dired, so instead of
changing dired-pop-to-buffer, why not just have the user customize
window-nest to t if the user wants the behavior you describe?

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> OK, but (i) this seems unrelated to the issue you originally raised in
> this bug,

It fixes the issue I raised in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1806#65
that describes the remaining problem with the current behavior of Dired.

We were unable to fix it before implementing `window-nest'.

> and (ii) surely this is not special to Dired, so instead of
> changing dired-pop-to-buffer, why not just have the user customize
> window-nest to t if the user wants the behavior you describe?

I think it's a plain bug to resize unrelated windows,
not a behavior some users might prefer.

As for setting `window-nest' to t by default, I don't know
how it would affect other window-related functionality.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> I think it's a plain bug to resize unrelated windows,
> not a behavior some users might prefer.

Is it OK to fix it?  I feel ashamed to see in e.g. today's podcast at
http://kennym.github.com/blog/2011/10/10/emacs-dired-mode-the-basics/
(from 5:50 to 6:15) that we have not yet fixed this ugly bug.

bug#1806: dired-pop-to-buffer in wrong place

[Roland Winkler]

On Wed Jan 7 2009 Juri Linkov wrote:
> > Can someone comment on these?
> 
> `proced-send-signal' is a recent change:
> 
> 2009-01-03  Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>
> 	* proced.el (proced-send-signal):
>         Use fit-window-to-buffer instead of dired-pop-to-buffer.
> 
> Roland, maybe we need a general function for both Proced and
> Dired?

When I changed proced to use fit-window-to-buffer, this change was
inspired by the changed code of dired-pop-to-buffer. Later I
realized that this doesn't always give the old behavior of
dired-pop-to-buffer which in my opinion was more appropriate than
the new code (but I hadn't found time yet to look into this more
carefully). So yes, I agree that probably it would be best to have a
function that gives the old behavior which can be used by both dired
and proced. And maybe the new function will be useful for other
packages, too.

Roland

bug#1806: dired-pop-to-buffer in wrong place

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]


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


[-- Attachment #2: Type: text/html, Size: 8850 bytes --]

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >   (cond ((> (frame-width) (window-width window))

It might be better to use (not (window-full-width-p window)) here.
Comparing `frame-width' and `window-width' is not always reliable.

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

IIUC you mostly use a

   (delete-other-windows)
   (split-window-vertically)
   (org-switch-to-buffer-other-window ...)

paradigm which avoids most of the pitfalls raised by Juri.  So I think
you are not really bothered by the problems discussed here.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> is not desirable.  One exception is displaying a list of files in Dired,
> and another is displaying the Calendar window.  Maybe there are a few
> of others.

For buffers showing information directly linked to the minibuffer (such
as Dired's file list, and maybe also *Completions*), it might make sense
to make an exception, indeed.
OTOH, I don't understand why you feel the same way for the Calendar window.


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> is not desirable.  One exception is displaying a list of files in Dired,
>> and another is displaying the Calendar window.  Maybe there are a few
>> of others.
>
> For buffers showing information directly linked to the minibuffer (such
> as Dired's file list, and maybe also *Completions*), it might make sense
> to make an exception, indeed.
> OTOH, I don't understand why you feel the same way for the Calendar window.

The Calendar window has a fixed height of 7 lines, and when
`split-width-threshold' is nil or the current frame is not wide,
it creates a nice small window with the height exactly fit
into these 7 lines.

But Calendar in a horizontally split window is currently very ugly:
there is small text part at the beginning of the window with almost
70 empty lines below.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1806: dired-pop-to-buffer in wrong place

[Stefan Monnier]

> But Calendar in a horizontally split window is currently very ugly:
> there is small text part at the beginning of the window with almost
> 70 empty lines below.

And if the frame is wide and you set split-width-threshold to nil you
get a silly window with only 75 columns used and the rest is empty.

Looks just as ugly to me.  The advantage of the "side window" layout is
that when I then pop up the diary buffer (as I always end up doing), it
makes good use of those 70 lines, whereas with your layout, the diary
buffer doesn't make use of those extra columns.

I'm not saying you're wrong, but just that this is not as clear cut as
the "dired files list".


        Stefan

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > After 2008-12-11 change to window.el and dired.el that fixed the bug #1488,
 > I have difficulties using dired.
 >
 > Before this change, running a dired operation on many files displayed
 > a pop-up window *below* the dired buffer and immediately *above* the
 > minibuffer.  This is the most convenient place to display a list of
 > file names, because it is near the minibuffer where the user types more
 > input for the command (a shell command or a directory to copy files to).

This should now work again as before.  If the dired buffer is not
immediately *above* the minibuffer, the file names are shown below the
dired buffer.  I also introduced a new default value for
`window-combination-limit' which should assure that fitting the window
to the buffer does not steal space from any window below.

 > I've just looked at the old behavior from the December CVS state,
 > and noticed that it behaved more conveniently than we are currently
 > discussing.  It displayed a list of files immediately above the
 > minibuffer.  This is convenient because when the minibuffer says:
 >
 >   ! on * [5 files]:
 >
 > then a list of these 5 files is very near above, so there is no need
 > to search for this list elsewhere on the current frame.  Maybe we
 > should have a special function to display a buffer above the minibuffer
 > (e.g. `pop-to-buffer-above-minibuffer')?

The action function `display-buffer-at-bottom' should do that so people
who prefer this are able to do the necessary customizations.

If there's anything missing please tell me.

Thanks, martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> If there's anything missing please tell me.

Thanks for enhancements.  There is one unfortunate regression
where a large almost empty window is displayed with just two lines
instead of a narrow window like in previous versions.  One test case
is typing !, or C, or R in Dired on two marked files when dired-shrink-to-fit
is t.  dired-pop-to-buffer should take care of this, but it doesn't work.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Thanks for enhancements.  There is one unfortunate regression
 > where a large almost empty window is displayed with just two lines
 > instead of a narrow window like in previous versions.  One test case
 > is typing !, or C, or R in Dired on two marked files when dired-shrink-to-fit
 > is t.  dired-pop-to-buffer should take care of this, but it doesn't work.

`dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is
no longer consulted.  You have to enable `temp-buffer-resize-mode'.  If
you really insist on handling dired's pop-up buffers separately, I can
do that by binding `temp-buffer-resize-mode' appropriately, but I'd
rather have a common solution for handling all temporary windows in the
same manner.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> You have to enable `temp-buffer-resize-mode'.

I tried to enable `temp-buffer-resize-mode', and with a large list of files
it seems to ignore `window-combination-limit', i.e. the temporary window
steals space from the window below.  A sample test case is:
`M-x temp-buffer-resize-mode', in a Dired window `C-x 3 C-x 2 m m m ...'
(mark 100 files), `!' (`dired-do-shell-command') steals space from the
window below, and `C-g' doesn't restore the initial window configuration.

Is this because `window-combination-limit' is not taken into account?
I see that its default value is `temp-buffer-resize', the same unchanged
value used in the test above.

I also tried a new action `display-buffer-at-bottom', and it doesn't
seem quite right yet.  With the same configuration (`C-x 3 C-x 2'),
and two marked files it displays a large almost empty window with just
two lines.  `temp-buffer-resize-mode' helps to narrow it, but I still wonder
why this window is not frame'e full-width?  I mean the idea was to display
a list of files near the minibuffer prompt of the left side of the frame,
but this list is displayed on the right side of the frame.

> `dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is
> no longer consulted.
> If you really insist on handling dired's pop-up buffers separately,
> I can do that by binding `temp-buffer-resize-mode' appropriately, but
> I'd rather have a common solution for handling all temporary windows
> in the same manner.

There is nothing wrong when a package uses a local variable
that changes the general behavior.  So `dired-mark-pop-up' could still
call `dired-pop-to-buffer' that will bind `temp-buffer-resize-mode'
according to the value of `dired-shrink-to-fit'.  This assumes that
`dired-pop-to-buffer' is the right name for this functionality.
Otherwise, it could be marked obsolete.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > I tried to enable `temp-buffer-resize-mode', and with a large list of files
 > it seems to ignore `window-combination-limit', i.e. the temporary window
 > steals space from the window below.  A sample test case is:
 > `M-x temp-buffer-resize-mode', in a Dired window `C-x 3 C-x 2 m m m ...'
 > (mark 100 files), `!' (`dired-do-shell-command') steals space from the
 > window below, and `C-g' doesn't restore the initial window configuration.
 >
 > Is this because `window-combination-limit' is not taken into account?
 > I see that its default value is `temp-buffer-resize', the same unchanged
 > value used in the test above.

No.  It's because resizing a window is allowed to steal space from _any_
other window on the frame.  That is, it will preferably steal space from
all other windows in the same combination (the upper window in our
case).  But if that is not sufficient, it can steal space from any other
window on the same frame.  We could make this optional but is it worth
the effort?

 > I also tried a new action `display-buffer-at-bottom', and it doesn't
 > seem quite right yet.  With the same configuration (`C-x 3 C-x 2'),
 > and two marked files it displays a large almost empty window with just
 > two lines.  `temp-buffer-resize-mode' helps to narrow it, but I still wonder
 > why this window is not frame'e full-width?

I can add that if you want.  I suppose that your initial configuration
was that of >= 2 side-by-side windows at the bottom of the frame?

 > I mean the idea was to display
 > a list of files near the minibuffer prompt of the left side of the frame,
 > but this list is displayed on the right side of the frame.

Aha.  So shall I split/reuse the left bottom window?  Or shall I split
the root window immediately?

 >> `dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is
 >> no longer consulted.
 >> If you really insist on handling dired's pop-up buffers separately,
 >> I can do that by binding `temp-buffer-resize-mode' appropriately, but
 >> I'd rather have a common solution for handling all temporary windows
 >> in the same manner.
 >
 > There is nothing wrong when a package uses a local variable
 > that changes the general behavior.  So `dired-mark-pop-up' could still
 > call `dired-pop-to-buffer' that will bind `temp-buffer-resize-mode'
 > according to the value of `dired-shrink-to-fit'.  This assumes that
 > `dired-pop-to-buffer' is the right name for this functionality.
 > Otherwise, it could be marked obsolete.

The question is whether we want one general setting to handle this.  I
intend to use this for `proced-with-processes-buffer' and vc-... buffers
too - adding a separate variable like `dired-shrink-to-fit' for each of
these seems some kind of proliferation.  Personally, I'd prefer to
declare `dired-shrink-to-fit' obsolete.

Note that I have added an option `temp-buffer-resize-regexps' which can
be used to turn off resizing in selected buffers.  I could invert the
meaning of this or do something different.  Any ideas?

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> It's because resizing a window is allowed to steal space from _any_
> other window on the frame.  That is, it will preferably steal space from
> all other windows in the same combination (the upper window in our
> case).  But if that is not sufficient, it can steal space from any other
> window on the same frame.  We could make this optional but is it worth
> the effort?

Then `temp-buffer-resize-mode' is not suitable for Dired and other
similar packages (Proced, VC).  When `temp-buffer-resize-mode' is disabled,
`dired-mark-pop-up' works correctly for a large list of files because it
doesn't steal space from other windows.  Its only drawback currently is
that it doesn't call `fit-window-to-buffer' for a small number of files.
So maybe a more suitable name would be `temp-buffer-shrink-to-fit-mode'
or some another name like that.  What is essential is that it shouldn't steal
space from other windows, but should give away its empty space to the
original Dired window (as `fit-window-to-buffer' does in `dired-pop-to-buffer').
This was the original behavior of this feature in Dired.

>> I also tried a new action `display-buffer-at-bottom', and it doesn't
>> seem quite right yet.  With the same configuration (`C-x 3 C-x 2'),
>> and two marked files it displays a large almost empty window with just
>> two lines.  `temp-buffer-resize-mode' helps to narrow it, but I still wonder
>> why this window is not frame'e full-width?
>
> I can add that if you want.  I suppose that your initial configuration
> was that of >= 2 side-by-side windows at the bottom of the frame?

Yes, 2 side-by-side windows at the bottom of the frame.

>> I mean the idea was to display
>> a list of files near the minibuffer prompt of the left side of the frame,
>> but this list is displayed on the right side of the frame.
>
> Aha.  So shall I split/reuse the left bottom window?  Or shall I split
> the root window immediately?

If now is possible to split the root window immediately, then maybe
it would be better to try doing so.

> The question is whether we want one general setting to handle this.  I
> intend to use this for `proced-with-processes-buffer' and vc-... buffers
> too - adding a separate variable like `dired-shrink-to-fit' for each of
> these seems some kind of proliferation.  Personally, I'd prefer to
> declare `dired-shrink-to-fit' obsolete.

Then a new function with a name like `with-temp-buffer-window-pop-up'
might be necessary to use it in Dired, Proced, VC that will work
like `dired-pop-to-buffer' does when `dired-shrink-to-fit' has
its default value t.  Please note also that it has this comment:

  (defvar dired-shrink-to-fit t
  ;; I see no reason ever to make this nil -- rms.

So `dired-shrink-to-fit' could be declared obsolete with functions
acting like its value is t.

> Note that I have added an option `temp-buffer-resize-regexps' which can
> be used to turn off resizing in selected buffers.  I could invert the
> meaning of this or do something different.  Any ideas?

You just unified a lot of scattered options (`special-display-regexps',
`special-display-buffer-names') to one option `display-buffer-alist',
but now reversed the direction of development by adding a new specific
`temp-buffer-resize-regexps' ;-)  When following the initial design,
`display-buffer-alist' should be able to do the same with
a corresponding action or property without need to add a new variable.
Is this possible to do with the current implementation?

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> It's because resizing a window is allowed to steal space from _any_
 >> other window on the frame.  That is, it will preferably steal space from
 >> all other windows in the same combination (the upper window in our
 >> case).  But if that is not sufficient, it can steal space from any other
 >> window on the same frame.  We could make this optional but is it worth
 >> the effort?
 >
 > Then `temp-buffer-resize-mode' is not suitable for Dired and other
 > similar packages (Proced, VC).  When `temp-buffer-resize-mode' is disabled,
 > `dired-mark-pop-up' works correctly for a large list of files because it
 > doesn't steal space from other windows.  Its only drawback currently is
 > that it doesn't call `fit-window-to-buffer' for a small number of files.

The problem is that we don't know beforehand how small the number of
files is going to be and how much space `fit-window-to-buffer' will make
out of it.  We had that already a number of times ...

 > So maybe a more suitable name would be `temp-buffer-shrink-to-fit-mode'
 > or some another name like that.  What is essential is that it shouldn't steal
 > space from other windows, but should give away its empty space to the
 > original Dired window (as `fit-window-to-buffer' does in `dired-pop-to-buffer').
 > This was the original behavior of this feature in Dired.

Do we really care?  I think that users who mark a large number of files
usually don't do that with other windows around.  OTOH we could try to
make `fit-window-to-buffer' always affect only windows in the same
combination.  Or do so for `temp-buffer-resize-mode' only.

 > If now is possible to split the root window immediately, then maybe
 > it would be better to try doing so.

Just that splitting the root will resize all windows proportionally and
I just have another thread were people don't like that (recall that you
want to do that for a large number of files).

 > Then a new function with a name like `with-temp-buffer-window-pop-up'
 > might be necessary to use it in Dired, Proced, VC

VC currently doesn't use `temp-buffer-resize-mode' and I'm not sure
whether we should use `with-temp-buffer-window' for it.

 > that will work
 > like `dired-pop-to-buffer' does when `dired-shrink-to-fit' has
 > its default value t.  Please note also that it has this comment:
 >
 >   (defvar dired-shrink-to-fit t
 >   ;; I see no reason ever to make this nil -- rms.
 >
 > So `dired-shrink-to-fit' could be declared obsolete with functions
 > acting like its value is t.

We can't.  Too many people don't like to automatically fit windows to
their buffers.  They must be able to turn that off.

 > You just unified a lot of scattered options (`special-display-regexps',
 > `special-display-buffer-names') to one option `display-buffer-alist',
 > but now reversed the direction of development by adding a new specific
 > `temp-buffer-resize-regexps' ;-)  When following the initial design,
 > `display-buffer-alist' should be able to do the same with
 > a corresponding action or property without need to add a new variable.
 > Is this possible to do with the current implementation?

It was earlier via `special-display-buffer-names' and
`special-display-regexps' and is now via `display-buffer-alist'.  You
just have to write the corresponding buffer display function.  The
problem is that nobody liked my earlier approach to combine specifiers.
So you now have to code within these functions how you want to display
the buffer and possibly resize its window.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> Just that splitting the root will resize all windows proportionally and
> I just have another thread were people don't like that (recall that you
> want to do that for a large number of files).

Yes, there are more problems with `display-buffer-at-bottom' that could
be fixed later.  This is why I don't propose to make it default now.
But still we should fix the problems with the current default action
`display-buffer-below-selected' because they are regressions.

>> Then a new function with a name like `with-temp-buffer-window-pop-up'
>> might be necessary to use it in Dired, Proced, VC
>
> VC currently doesn't use `temp-buffer-resize-mode' and I'm not sure
> whether we should use `with-temp-buffer-window' for it.

Like Dired and Proced, VC shrinks the window to fit the buffer in
`log-edit-show-files', so it could use `with-temp-buffer-window' too
if it will retain the original behavior in the affected commands.

> It was earlier via `special-display-buffer-names' and
> `special-display-regexps' and is now via `display-buffer-alist'.  You
> just have to write the corresponding buffer display function.  The
> problem is that nobody liked my earlier approach to combine specifiers.
> So you now have to code within these functions how you want to display
> the buffer and possibly resize its window.

There is no need to combine specifiers and no need to add
`temp-buffer-resize-regexps'.  In your current implementation
it's perfectly possible to use the following call in `dired-mark-pop-up':

	  (with-temp-buffer-window
	   buffer
	   (cons 'display-buffer-below-selected
		 '((fit-window-to-buffer . t)))
           ...

and to add the following code to `display-buffer-below-selected'
(copied and adapted from `dired-pop-to-buffer'):

(defun display-buffer-below-selected (buffer alist)
  "Try displaying BUFFER in a window below the selected window.
This either splits the selected window or reuses the window below
the selected one."
  (let (window)
    (or (and (not (frame-parameter nil 'unsplittable))
	     (setq window (window--try-to-split-window (selected-window)))
	     (window--display-buffer
	      buffer window 'window display-buffer-mark-dedicated))
	(and (setq window (window-in-direction 'below))
	     (not (window-dedicated-p window))
	     (window--display-buffer
	      buffer window 'reuse display-buffer-mark-dedicated)))
    ;; See Bug#12281.
    (set-window-start window (point-min))
    ;; If fit-window-to-buffer is t, make its window fit its contents.
    (when (cdr (assq 'fit-window-to-buffer alist))
      ;; Try to not delete window when we want to display less than
      ;; `window-min-height' lines.
      (fit-window-to-buffer window nil 1))
    window))

> Too many people don't like to automatically fit windows to
> their buffers.  They must be able to turn that off.

With the fixes above, users will be able to turn that off by customizing
`display-buffer-alist' to the following value (this should be done via the
Customization UI, but `setq' is used below for testing purposes):

(setq display-buffer-alist '(("Marked Files" .
                              (display-buffer-below-selected
                               (fit-window-to-buffer . nil)))))

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Like Dired and Proced, VC shrinks the window to fit the buffer in
 > `log-edit-show-files', so it could use `with-temp-buffer-window' too
 > if it will retain the original behavior in the affected commands.

Maybe.  But when a buffer already exists, `with-temp-buffer-window' is
not suitable since it erases its contents.

 > There is no need to combine specifiers and no need to add
 > `temp-buffer-resize-regexps'.  In your current implementation
 > it's perfectly possible to use the following call in `dired-mark-pop-up':
 >
 > 	  (with-temp-buffer-window
 > 	   buffer
 > 	   (cons 'display-buffer-below-selected
 > 		 '((fit-window-to-buffer . t)))
 >            ...
 >
 > and to add the following code to `display-buffer-below-selected'
 > (copied and adapted from `dired-pop-to-buffer'):
 >
 > (defun display-buffer-below-selected (buffer alist)
 >   "Try displaying BUFFER in a window below the selected window.
 > This either splits the selected window or reuses the window below
 > the selected one."
 >   (let (window)
 >     (or (and (not (frame-parameter nil 'unsplittable))
 > 	     (setq window (window--try-to-split-window (selected-window)))
 > 	     (window--display-buffer
 > 	      buffer window 'window display-buffer-mark-dedicated))
 > 	(and (setq window (window-in-direction 'below))
 > 	     (not (window-dedicated-p window))
 > 	     (window--display-buffer
 > 	      buffer window 'reuse display-buffer-mark-dedicated)))
 >     ;; See Bug#12281.
 >     (set-window-start window (point-min))
 >     ;; If fit-window-to-buffer is t, make its window fit its contents.
 >     (when (cdr (assq 'fit-window-to-buffer alist))
 >       ;; Try to not delete window when we want to display less than
 >       ;; `window-min-height' lines.
 >       (fit-window-to-buffer window nil 1))
 >     window))

How would we handle the case where `window--try-to-split-window' fails
for the selected window and some other window (like the frame's bottom
window) gets split?

 >> Too many people don't like to automatically fit windows to
 >> their buffers.  They must be able to turn that off.
 >
 > With the fixes above, users will be able to turn that off by customizing
 > `display-buffer-alist' to the following value (this should be done via the
 > Customization UI, but `setq' is used below for testing purposes):
 >
 > (setq display-buffer-alist '(("Marked Files" .
 >                               (display-buffer-below-selected
 >                                (fit-window-to-buffer . nil)))))

And how would they handle the frame bottom window case sketched above?

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> How would we handle the case where `window--try-to-split-window' fails
> for the selected window and some other window (like the frame's bottom
> window) gets split?

This case is exceptional, but maybe handling of the `fit-window-to-buffer'
specifier could be added to some other actions where it makes sense?

>> (setq display-buffer-alist '(("Marked Files" .
>>                               (display-buffer-below-selected
>>                                (fit-window-to-buffer . nil)))))
>
> And how would they handle the frame bottom window case sketched above?

With (setq display-buffer-alist
           '(("Marked Files" . (nil (fit-window-to-buffer . nil)))))

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> How would we handle the case where `window--try-to-split-window' fails
 >> for the selected window and some other window (like the frame's bottom
 >> window) gets split?
 >
 > This case is exceptional, but maybe handling of the `fit-window-to-buffer'
 > specifier could be added to some other actions where it makes sense?
 >
 >>> (setq display-buffer-alist '(("Marked Files" .
 >>>                               (display-buffer-below-selected
 >>>                                (fit-window-to-buffer . nil)))))
 >> And how would they handle the frame bottom window case sketched above?
 >
 > With (setq display-buffer-alist
 >            '(("Marked Files" . (nil (fit-window-to-buffer . nil)))))

I see.  My knowledge of `display-buffer-alist' is certainly much worse
than yours.  Could you patch this along these lines?  I think Chong will
agree, if we only can get rid of the `temp-buffer-resize-regexps' stuff.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> I see.  My knowledge of `display-buffer-alist' is certainly much worse
> than yours.  Could you patch this along these lines?  I think Chong will
> agree, if we only can get rid of the `temp-buffer-resize-regexps' stuff.

Of course I know less than you.  I don't know what problems you
intended to fix with new options that you implemented.  Particularly
I didn't know that you intended to use `temp-buffer-resize-mode' in
buffers displayed without `display-buffer'.  What I wanted to do
is just to help you to fix 2 regressions in Dired to be able to
close bug#1806.  One regression is related to the need to use
`fit-window-to-buffer' and `set-window-start' like in the previously
used `dired-pop-to-buffer'.  The second regression is that the value `t'
of `window-combination-limit' is ignored, so `fit-window-to-buffer'
steals space from the window below.  I have no idea how to fix that.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Of course I know less than you.  I don't know what problems you
 > intended to fix with new options that you implemented.  Particularly
 > I didn't know that you intended to use `temp-buffer-resize-mode' in
 > buffers displayed without `display-buffer'.

This has no relation to the problem at hand.  It would have been an easy
fix for functions that currently don't use `with-output-to-temp-buffer'.

 > What I wanted to do
 > is just to help you to fix 2 regressions in Dired to be able to
 > close bug#1806.  One regression is related to the need to use
 > `fit-window-to-buffer'

I don't understand you.  When `temp-buffer-resize-mode' is enabled, I
try to do `fit-window-to-buffer'.

 > and `set-window-start' like in the previously
 > used `dired-pop-to-buffer'.

You never talked about `set-window-start' in the present context before.
`with-temp-buffer-window' goes to `point-min' in the buffer it displays
- is that not sufficient?

 > The second regression is that the value `t'
 > of `window-combination-limit' is ignored,

I don't understand again.  If `window-combination-limit' is t it remains
t and is obeyed.  If it's 'temp-buffer or 'temp-buffer-resize it changes
its value to t.

 > so `fit-window-to-buffer'
 > steals space from the window below.

`fit-window-to-buffer' steals space from the lower window if and only if
the upper window is not large enough.  Otherwise it steals only from the
upper window.  What do you expect me to do if the upper window is not
large enough?  I do not have a solution for this because at the time I
display the buffer I don't know how large the window is supposed to be.
I can (1) do the calculations of `fit-window-to-buffer' before trying to
split the window and (2) not split if the window won't fit and reuse the
lower window instead.  But such a change is too invasive for the moment
and wouldn't help anyway if the lower window is too small.  You simply
ask too much here :-(

 > I have no idea how to fix that.

I'm currently struggling with a solution based on your ideas but am not
yet sure whether I'll be able to come up with a fix in the next days.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> and `set-window-start' like in the previously
>> used `dired-pop-to-buffer'.
>
> You never talked about `set-window-start' in the present context before.
> `with-temp-buffer-window' goes to `point-min' in the buffer it displays
> - is that not sufficient?

A month ago in revno:109790 you added two lines to `dired-pop-to-buffer':

  ;; See Bug#12281.
  (set-window-start nil (point-min))

so I wondered if this is still necessary after the recent redesign of
`dired-mark-pop-up' to not cause the same bug as reported in bug#12281.

>> The second regression is that the value `t'
>> of `window-combination-limit' is ignored,
>
> I don't understand again.  If `window-combination-limit' is t it remains
> t and is obeyed.  If it's 'temp-buffer or 'temp-buffer-resize it changes
> its value to t.

Some time ago setting `window-combination-limit' to t allowed
`fit-window-to-buffer' not to steal space from the lower window.
Only resizing at the cost of the upper window was allowed because it
has a common parent when `window-combination-limit' is t.  Now it seems
it has no effect and `fit-window-to-buffer' ignores the fact that
windows were split with `window-combination-limit' is t.

> `fit-window-to-buffer' steals space from the lower window if and only if
> the upper window is not large enough.  Otherwise it steals only from the
> upper window.  What do you expect me to do if the upper window is not
> large enough?  I do not have a solution for this because at the time I
> display the buffer I don't know how large the window is supposed to be.
> I can (1) do the calculations of `fit-window-to-buffer' before trying to
> split the window and (2) not split if the window won't fit and reuse the
> lower window instead.  But such a change is too invasive for the moment
> and wouldn't help anyway if the lower window is too small.

The problem is that it steals space when the upper window is large
and the *Marked files* buffer is large.  But it can't be completely
displayed anyway, so there is no need to resize the lower window.

When the upper window is small to split, there is no problem -
it just reuses the lower window.

> You simply ask too much here :-(

I'm not asking anything special.  I just believe that I found a bug in
`fit-window-to-buffer' and `window-combination-limit'.  Some time ago
`fit-window-to-buffer' obeyed the value t of `window-combination-limit',
and I don't understand why it's different now.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > A month ago in revno:109790 you added two lines to `dired-pop-to-buffer':
 >
 >   ;; See Bug#12281.
 >   (set-window-start nil (point-min))
 >
 > so I wondered if this is still necessary after the recent redesign of
 > `dired-mark-pop-up' to not cause the same bug as reported in bug#12281.

Hopefully not.  Otherwise _all_ uses of `with-output-to-temp-buffer' and
`with-temp-buffer-window' - which both do (goto-char (point-min)) in the
buffer to be displayed - would be faulty in this regard.

 > Some time ago setting `window-combination-limit' to t allowed
 > `fit-window-to-buffer' not to steal space from the lower window.

Your memory must be wrong.  At least in Emacs 24.1 I can easily shrink
the lower window by fitting the midlle window to its buffer.

 > Only resizing at the cost of the upper window was allowed because it
 > has a common parent when `window-combination-limit' is t.  Now it seems
 > it has no effect and `fit-window-to-buffer' ignores the fact that
 > windows were split with `window-combination-limit' is t.

Setting `window-combination-limit' had and has only one effect in this
regard - that resizing a window _preferably_ resizes that window's buddy
first.  But if this is not sufficient, any other window can get resized.
Try to do some random splitting with `window-combination-limit' t and
then do M-x `maximize-window' for any version starting with 24.1.

 > The problem is that it steals space when the upper window is large

... I suppose you mean "when the upper window is small" here ...

 > and the *Marked files* buffer is large.  But it can't be completely
 > displayed anyway, so there is no need to resize the lower window.

IIUC `fit-window-to-buffer' always tried to display as much as possible
within limits imposed, for example, by `temp-buffer-max-height'.  Can
you tell me when and where it restricted itself to just some area of the
frame?

 > I'm not asking anything special.  I just believe that I found a bug in
 > `fit-window-to-buffer' and `window-combination-limit'.  Some time ago
 > `fit-window-to-buffer' obeyed the value t of `window-combination-limit',
 > and I don't understand why it's different now.

Please point me to any version where you saw that.  Maybe I'm missing
something.

Obviously all I say here does not preclude that we inhibit resizing any
other but the buddy window in `fit-window-to-buffer'.  But we have to
agree on such a restriction first.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> The problem is that it steals space when the upper window is large
>
> ... I suppose you mean "when the upper window is small" here ...

When a window has 30 lines in height, I call it "large" :-)

> IIUC `fit-window-to-buffer' always tried to display as much as possible
> within limits imposed, for example, by `temp-buffer-max-height'.  Can
> you tell me when and where it restricted itself to just some area of the
> frame?

I'll try to provide the exact details:

1. When the Dired window is small (less than 7 lines in height),
   there is no problem because it reuses the lower window.

2. When the Dired window is large (more than 7 lines in height)
   and a list of marked files is small:

2.1. When `window-combination-limit' is nil,
     the result of `dired-mark-pop-up' is horribly ugly
     (when `temp-buffer-resize-mode' is enabled).  But thank you
     `window-combination-limit' is not nil anymore,
     so there is no problem now.

2.2. When `window-combination-limit' is non-nil, the result is still
     bad looking because `fit-window-to-buffer' is missing like in the
     original version of `dired-pop-to-buffer'.  This is a regression.

2.3. When a list of files is too large to fit into split windows, it
     resizes the lower window.  What I misremembered is that actually it
     never tried to avoid resizing the lower window.  Sorry for my amnesia.
     This is not a regression.  Its result looks like when
     `window-combination-limit' is nil, but since a large list of files
     is rarely displayed in Dired, this is a minor problem.

So the main problem that remains is the need to use `fit-window-to-buffer'.
I see three possible variants to fix this:

1. Call `fit-window-to-buffer' directly in `dired-mark-pop-up'.

2. Call `fit-window-to-buffer' in `display-buffer-below-selected'
   using a new action specifier.

3. Enable `temp-buffer-resize-mode'.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]

 >>> The problem is that it steals space when the upper window is large
 >> ... I suppose you mean "when the upper window is small" here ...
 >
 > When a window has 30 lines in height, I call it "large" :-)

So splitting a 30 lines window is not enough for getting you enough
space for the Marked Files buffer.  How many lines would you need?

 >> IIUC `fit-window-to-buffer' always tried to display as much as possible
 >> within limits imposed, for example, by `temp-buffer-max-height'.  Can
 >> you tell me when and where it restricted itself to just some area of the
 >> frame?
 >
 > I'll try to provide the exact details:
 >
 > 1. When the Dired window is small (less than 7 lines in height),
 >    there is no problem because it reuses the lower window.

Because `window--try-to-split-window' fails immediately, I presume.

 > 2. When the Dired window is large (more than 7 lines in height)
 >    and a list of marked files is small:
 >
 > 2.1. When `window-combination-limit' is nil,
 >      the result of `dired-mark-pop-up' is horribly ugly
 >      (when `temp-buffer-resize-mode' is enabled).  But thank you
 >      `window-combination-limit' is not nil anymore,
 >      so there is no problem now.

What you probably intend to say between these lines is that users should
not have to enable `temp-buffer-resize-mode' to avoid that horribly ugly
result.

 > 2.2. When `window-combination-limit' is non-nil, the result is still
 >      bad looking because `fit-window-to-buffer' is missing like in the
 >      original version of `dired-pop-to-buffer'.  This is a regression.

This is the part I don't understand.  Suppose with Emacs -Q I do

C-x 2
(setq window-combination-limit t)
(temp-buffer-resize-mode 1)
C-x d

for some directory, mark some files and type D, the space for the
*Deletions* window is taken from the upper window only.

 > 2.3. When a list of files is too large to fit into split windows, it
 >      resizes the lower window.  What I misremembered is that actually it
 >      never tried to avoid resizing the lower window.  Sorry for my amnesia.
 >      This is not a regression.  Its result looks like when
 >      `window-combination-limit' is nil, but since a large list of files
 >      is rarely displayed in Dired, this is a minor problem.

We agree here.

 > So the main problem that remains is the need to use `fit-window-to-buffer'.

I suppose you intend "the need to enable `temp-buffer-resize-mode'"
here.  `fit-window-to-buffer' has been used all the time.

 > I see three possible variants to fix this:
 >
 > 1. Call `fit-window-to-buffer' directly in `dired-mark-pop-up'.

This solves the problem at hand but is no general fix.  In addition we'd
have to maintain things like `dired-shrink-to-fit' forever.

 > 2. Call `fit-window-to-buffer' in `display-buffer-below-selected'
 >    using a new action specifier.

This is still not a complete solution since `fit-window-to-buffer'
should apply whenever we create a new window.

 > 3. Enable `temp-buffer-resize-mode'.

 From your and Chong less than enthusiastic comments this is no good.

I think your idea to pass an appropriate alist entry to `display-buffer'
was best.  I attach a patch which should do that, in principle (actually
I just revived the respective part from my old specifiers approach).

Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a
corresponding entry to `display-buffer-alist' as you proposed earlier.
(Someone would have to formulate that for users nicely and in the
appropriate context.)

The resizing request by `temp-buffer-resize-mode' is still done
explicitly in the corresponding hook but this can be moved to
`display-buffer' in a similar fashion.  Unless we decide that
`temp-buffer-resize-mode' should be removed, that is, moved to
`display-buffer-alist'.

martin

[-- Attachment #2: window-height-width.diff --]
[-- Type: text/plain, Size: 28399 bytes --]

=== modified file 'etc/NEWS'
--- etc/NEWS	2012-09-25 04:13:02 +0000
+++ etc/NEWS	2012-09-28 09:42:19 +0000
@@ -723,14 +723,11 @@
 
 *** New macro `with-temp-buffer-window'.
 
-*** New options `temp-buffer-resize-frames' and
-`temp-buffer-resize-regexps'.
-
 *** `temp-buffer-resize-mode' no longer resizes windows that have been
 reused.
 
-*** New function `fit-frame-to-buffer' and new option
-`fit-frame-to-buffer-bottom-margin'.
+*** New function `fit-frame-to-buffer' and new options
+`fit-frame-to-buffer' and `fit-frame-to-buffer-bottom-margin'.
 
 *** New display action functions `display-buffer-below-selected',
 `display-buffer-at-bottom' and `display-buffer-in-previous-window'.
@@ -745,6 +742,9 @@
 *** New display action alist entry `previous-window', if non-nil,
 specifies window to reuse in `display-buffer-in-previous-window'.
 
+*** New display action alist entries `window-height' and `window-width'
+to specify size of new window created by `display-buffer'.
+
 *** The following variables are obsolete, as they can be replaced by
 appropriate entries in the `display-buffer-alist' function introduced
 in Emacs 24.1:

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-09-25 08:20:05 +0000
+++ lisp/ChangeLog	2012-09-28 09:32:16 +0000
@@ -1,3 +1,32 @@
+2012-09-28  Martin Rudalics  <rudalics@gmx.at>
+
+	* window.el (window--display-buffer): New argument ALIST.  Obey
+	window-height and window-width alist entries.
+	(window--try-to-split-window): New argument ALIST.  Bind
+	window-combination-limit to t when the window's size shall be
+	changed and window-combination-limit equals `window-size'.
+	(display-buffer-in-atom-window)
+	(display-buffer-in-major-side-window)
+	(display-buffer-in-side-window, display-buffer-same-window)
+	(display-buffer-reuse-window, display-buffer-pop-up-frame)
+	(display-buffer-pop-up-window, display-buffer-below-selected)
+	(display-buffer-at-bottom, display-buffer-in-previous-window)
+	(display-buffer-use-some-window): Adjust all callers of
+	window--display-buffer and window--try-to-split-window.
+	(fit-frame-to-buffer): New option.
+	(fit-window-to-buffer): Can resize frames if fit-frame-to-buffer
+	is non-nil.
+
+	* help.el (temp-buffer-resize-frames)
+	(temp-buffer-resize-regexps): Remove options.
+	(temp-buffer-resize-mode): Adjust doc-string.
+	(resize-temp-buffer-window): Don't consult
+	temp-buffer-resize-regexps.  Use fit-frame-to-buffer instead of
+	temp-buffer-resize-frames.
+
+	* dired.el (dired-mark-pop-up): Call display-buffer-below-selected
+	with a fit-window-to-buffer alist entry.
+
 2012-09-25  Martin Rudalics  <rudalics@gmx.at>
 
 	* window.el (window--resize-child-windows): When resizing child

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2012-09-25 04:13:02 +0000
+++ lisp/dired.el	2012-09-28 09:03:53 +0000
@@ -2997,7 +2997,8 @@
 	(let ((split-height-threshold 0))
 	  (with-temp-buffer-window
 	   buffer
-	   (cons 'display-buffer-below-selected nil)
+	   (cons 'display-buffer-below-selected
+		 '((window-height . fit-window-to-buffer)))
 	   #'(lambda (window _value)
 	       (with-selected-window window
 		 (unwind-protect

=== modified file 'lisp/help.el'
--- lisp/help.el	2012-09-22 12:56:08 +0000
+++ lisp/help.el	2012-09-28 09:03:00 +0000
@@ -981,26 +981,6 @@
   :group 'help
   :version "24.2")
 
-(defcustom temp-buffer-resize-frames nil
-  "Non-nil means `temp-buffer-resize-mode' can resize frames.
-A frame can be resized if and only if its root window is a live
-window.  The height of the root window is subject to the values of
-`temp-buffer-max-height' and `window-min-height'."
-  :type 'boolean
-  :version "24.2"
-  :group 'help)
-
-(defcustom temp-buffer-resize-regexps nil
-  "List of regexps that inhibit Temp Buffer Resize mode.
-Any window of a buffer whose name matches one of these regular
-expressions is left alone by Temp Buffer Resize mode."
-  :type '(repeat
-	  :tag "Buffer"
-	  :value ""
-	  (regexp :format "%v"))
-  :version "24.3"
-  :group 'help)
-
 (define-minor-mode temp-buffer-resize-mode
   "Toggle auto-resizing temporary buffer windows (Temp Buffer Resize Mode).
 With a prefix argument ARG, enable Temp Buffer Resize mode if ARG
@@ -1014,9 +994,8 @@
 
 A window is resized only if it has been specially created for the
 buffer.  Windows that have shown another buffer before are not
-resized.  A window showing a buffer whose name matches any of the
-expressions in `temp-buffer-resize-regexps' is not resized.  A
-frame is resized only if `temp-buffer-resize-frames' is non-nil.
+resized.  A frame is resized only if `fit-frame-to-buffer' is
+non-nil.
 
 This mode is used by `help', `apropos' and `completion' buffers,
 and some others."
@@ -1034,33 +1013,28 @@
 Do not make WINDOW higher than `temp-buffer-max-height' nor
 smaller than `window-min-height'.  Do nothing if WINDOW is not
 vertically combined or some of its contents are scrolled out of
-view.  Do nothing if the name of WINDOW's buffer matches an
-expression in `temp-buffer-resize-regexps'."
+view."
   (setq window (window-normalize-window window t))
   (let ((buffer-name (buffer-name (window-buffer window))))
-    (unless (catch 'found
-	      (dolist (regexp temp-buffer-resize-regexps)
-		(when (string-match regexp buffer-name)
-		  (throw 'found t))))
-      (let ((height (if (functionp temp-buffer-max-height)
-			(with-selected-window window
-			  (funcall temp-buffer-max-height (window-buffer)))
-		      temp-buffer-max-height))
-	    (quit-cadr (cadr (window-parameter window 'quit-restore))))
-	(cond
-	 ;; Don't resize WINDOW if it showed another buffer before.
-	 ((and (eq quit-cadr 'window)
-	       (pos-visible-in-window-p (point-min) window)
-	       (window-combined-p window))
-	  (fit-window-to-buffer window height))
-	 ((and temp-buffer-resize-frames
-	       (eq quit-cadr 'frame)
-	       (eq window (frame-root-window window)))
-	  (let ((frame (window-frame window)))
-	    (fit-frame-to-buffer
-	     frame (+ (frame-height frame)
-		      (- (window-total-size window))
-		      height)))))))))
+    (let ((height (if (functionp temp-buffer-max-height)
+		      (with-selected-window window
+			(funcall temp-buffer-max-height (window-buffer)))
+		    temp-buffer-max-height))
+	  (quit-cadr (cadr (window-parameter window 'quit-restore))))
+      (cond
+       ;; Don't resize WINDOW if it showed another buffer before.
+       ((and (eq quit-cadr 'window)
+	     (pos-visible-in-window-p (point-min) window)
+	     (window-combined-p window))
+	(fit-window-to-buffer window height))
+       ((and fit-frame-to-buffer
+	     (eq quit-cadr 'frame)
+	     (eq window (frame-root-window window)))
+	(let ((frame (window-frame window)))
+	  (fit-frame-to-buffer
+	   frame (+ (frame-height frame)
+		    (- (window-total-size window))
+		    height))))))))
 
 ;;; Help windows.
 (defcustom help-window-select 'other

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-09-25 08:20:05 +0000
+++ lisp/window.el	2012-09-28 09:24:46 +0000
@@ -508,7 +508,7 @@
       (window-make-atom (window-parent window))
       ;; Display BUFFER in NEW and return NEW.
       (window--display-buffer
-       buffer new 'window display-buffer-mark-dedicated))))
+       buffer new 'window alist display-buffer-mark-dedicated))))
 
 (defun window--atom-check-1 (window)
   "Subroutine of `window--atom-check'."
@@ -706,7 +706,7 @@
       ;; does not get resized.
       (set-window-parameter new 'delete-window 'delete-side-window)
       ;; Install BUFFER in new window and return NEW.
-      (window--display-buffer buffer new 'window 'side))))
+      (window--display-buffer buffer new 'window alist 'side))))
 
 (defun delete-side-window (window)
   "Delete side window WINDOW."
@@ -814,7 +814,7 @@
 	;; ALIST (or, better, avoided in the "other" functions).
 	(or (and this-window
 		 ;; Reuse `this-window'.
-		 (window--display-buffer buffer this-window 'reuse 'side))
+		 (window--display-buffer buffer this-window 'reuse alist 'side))
 	    (and (or (not max-slots) (< slots max-slots))
 		 (or (and next-window
 			  ;; Make new window before `next-window'.
@@ -839,13 +839,14 @@
 			     window 'delete-window 'delete-side-window)
 			    window)))
 		   (set-window-parameter window 'window-slot slot)
-		   (window--display-buffer buffer window 'window 'side))
+		   (window--display-buffer buffer window 'window alist 'side))
 	    (and best-window
 		 ;; Reuse `best-window'.
 		 (progn
 		   ;; Give best-window the new slot value.
 		   (set-window-parameter best-window 'window-slot slot)
-		   (window--display-buffer buffer best-window 'reuse 'side)))))))))
+		   (window--display-buffer
+		    buffer best-window 'reuse alist 'side)))))))))
 
 (defun window--side-check (&optional frame)
   "Check the side window configuration of FRAME.
@@ -5077,7 +5078,7 @@
 		 (with-selected-window window
 		   (split-window-below))))))))
 
-(defun window--try-to-split-window (window)
+(defun window--try-to-split-window (window &optional alist)
   "Try to split WINDOW.
 Return value returned by `split-window-preferred-function' if it
 represents a live window, nil otherwise."
@@ -5085,9 +5086,14 @@
 	   (not (frame-parameter (window-frame window) 'unsplittable))
 	   (let* ((window-combination-limit
 		   ;; When `window-combination-limit' equals
-		   ;; `display-buffer' bind it to t so resizing steals
-		   ;; space preferably from the window that was split.
-		   (if (eq window-combination-limit 'display-buffer)
+		   ;; `display-buffer' or equals `resize-window' and a
+		   ;; `window-height' or `window-width' alist entry are
+		   ;; present, bind it to t so resizing steals space
+		   ;; preferably from the window that was split.
+		   (if (or (eq window-combination-limit 'display-buffer)
+			   (and (eq window-combination-limit 'window-size)
+				(or (cdr (assq 'window-height alist))
+				    (cdr (assq 'window-width alist)))))
 		       t
 		     window-combination-limit))
 		  (new-window
@@ -5144,7 +5150,7 @@
 	 (/ (- (window-total-height window) (window-total-height)) 2))
       (error nil))))
 
-(defun window--display-buffer (buffer window type &optional dedicated)
+(defun window--display-buffer (buffer window type &optional alist dedicated)
   "Display BUFFER in WINDOW and make its frame visible.
 TYPE must be one of the symbols `reuse', `window' or `frame' and
 is passed unaltered to `display-buffer-record-window'. Set
@@ -5159,6 +5165,58 @@
 	(set-window-dedicated-p window dedicated))
       (when (memq type '(window frame))
 	(set-window-prev-buffers window nil)))
+    (let ((parameter (window-parameter window 'quit-restore))
+	  (height (cdr (assq 'window-height alist)))
+	  (width (cdr (assq 'window-width alist))))
+      (when (or (memq type '(window frame))
+		(and (eq (car parameter) 'same)
+		     (memq (nth 1 parameter) '(window frame))))
+	;; Adjust height of new window or frame.
+	(cond
+	 ((not height))
+	 ((numberp height)
+	  (let* ((new-height
+		  (if (integerp height)
+		      height
+		    (round
+		     (* (window-total-size (frame-root-window window))
+			height))))
+		 (delta (- new-height (window-total-size window))))
+	    (cond
+	     ((and (window-resizable-p window delta nil 'safe)
+		   (window-combined-p window))
+	      (window-resize window delta nil 'safe))
+	     ((or (eq type 'frame)
+		  (and (eq (car parameter) 'same)
+		       (eq (nth 1 parameter) 'frame)))
+	      (set-frame-height
+	       (window-frame window)
+	       (+ (frame-height (window-frame window)) delta))))))
+	 ((functionp height)
+	  (ignore-errors (funcall height window))))
+	;; Adjust width of a window or frame.
+	(cond
+	 ((not width))
+	 ((numberp width)
+	  (let* ((new-width
+		  (if (integerp width)
+		      width
+		    (round
+		     (* (window-total-size (frame-root-window window) t)
+			width))))
+		 (delta (- new-width (window-total-size window t))))
+	    (cond
+	     ((and (window-resizable-p window delta t 'safe)
+		   (window-combined-p window t))
+	      (window-resize window delta t 'safe))
+	     ((or (eq type 'frame)
+		  (and (eq (car parameter) 'same)
+		       (eq (nth 1 parameter) 'frame)))
+	      (set-frame-width
+	       (window-frame window)
+	       (+ (frame-width (window-frame window)) delta))))))
+	 ((functionp width)
+	  (ignore-errors (funcall width window))))))
     window))
 
 (defun window--maybe-raise-frame (frame)
@@ -5400,7 +5458,7 @@
   (unless (or (cdr (assq 'inhibit-same-window alist))
 	      (window-minibuffer-p)
 	      (window-dedicated-p))
-    (window--display-buffer buffer (selected-window) 'reuse)))
+    (window--display-buffer buffer (selected-window) 'reuse alist)))
 
 (defun display-buffer--maybe-same-window (buffer alist)
   "Conditionally display BUFFER in the selected window.
@@ -5448,7 +5506,7 @@
 			      (get-buffer-window-list buffer 'nomini
 						      frames))))))
     (when (window-live-p window)
-      (prog1 (window--display-buffer buffer window 'reuse)
+      (prog1 (window--display-buffer buffer window 'reuse alist)
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame (window-frame window)))))))
 
@@ -5485,8 +5543,8 @@
     (when (and fun
 	       (setq frame (funcall fun))
 	       (setq window (frame-selected-window frame)))
-      (prog1 (window--display-buffer buffer window
-				     'frame display-buffer-mark-dedicated)
+      (prog1 (window--display-buffer
+	      buffer window 'frame alist display-buffer-mark-dedicated)
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame frame))))))
 
@@ -5511,11 +5569,11 @@
 			(not (frame-parameter frame 'unsplittable))))
 	       ;; Attempt to split largest or least recently used window.
 	       (setq window (or (window--try-to-split-window
-				 (get-largest-window frame t))
+				 (get-largest-window frame t) alist)
 				(window--try-to-split-window
-				 (get-lru-window frame t)))))
-      (prog1 (window--display-buffer buffer window
-				     'window display-buffer-mark-dedicated)
+				 (get-lru-window frame t) alist))))
+      (prog1 (window--display-buffer
+	      buffer window 'window alist display-buffer-mark-dedicated)
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame (window-frame window)))))))
 
@@ -5534,21 +5592,21 @@
       (and pop-up-windows
 	   (display-buffer-pop-up-window buffer alist))))
 
-(defun display-buffer-below-selected (buffer _alist)
+(defun display-buffer-below-selected (buffer alist)
   "Try displaying BUFFER in a window below the selected window.
 This either splits the selected window or reuses the window below
 the selected one."
   (let (window)
     (or (and (not (frame-parameter nil 'unsplittable))
-	     (setq window (window--try-to-split-window (selected-window)))
+	     (setq window (window--try-to-split-window (selected-window) alist))
 	     (window--display-buffer
-	      buffer window 'window display-buffer-mark-dedicated))
+	      buffer window 'window alist display-buffer-mark-dedicated))
 	(and (setq window (window-in-direction 'below))
 	     (not (window-dedicated-p window))
 	     (window--display-buffer
-	      buffer window 'reuse display-buffer-mark-dedicated)))))
+	      buffer window 'reuse alist display-buffer-mark-dedicated)))))
 
-(defun display-buffer-at-bottom (buffer _alist)
+(defun display-buffer-at-bottom (buffer alist)
   "Try displaying BUFFER in a window at the botom of the selected frame.
 This either splits the window at the bottom of the frame or the
 frame's root window, or reuses an existing window at the bottom
@@ -5556,20 +5614,20 @@
   (let (bottom-window window)
     (walk-window-tree (lambda (window) (setq bottom-window window)))
     (or (and (not (frame-parameter nil 'unsplittable))
-	     (setq window (window--try-to-split-window bottom-window))
+	     (setq window (window--try-to-split-window bottom-window alist))
 	     (window--display-buffer
-	      buffer window 'window display-buffer-mark-dedicated))
+	      buffer window 'window alist display-buffer-mark-dedicated))
 	(and (not (frame-parameter nil 'unsplittable))
 	     (setq window
 		   (condition-case nil
 		       (split-window (frame-root-window))
 		     (error nil)))
 	     (window--display-buffer
-	      buffer window 'window display-buffer-mark-dedicated))
+	      buffer window 'window alist display-buffer-mark-dedicated))
 	(and (setq window bottom-window)
 	     (not (window-dedicated-p window))
 	     (window--display-buffer
-	      buffer window 'reuse display-buffer-mark-dedicated)))))
+	      buffer window 'reuse alist display-buffer-mark-dedicated)))))
 
 (defun display-buffer-in-previous-window (buffer alist)
   "Display BUFFER in a window previously showing it.
@@ -5625,7 +5683,7 @@
 	(setq best-window window)))
     ;; Return best or second best window found.
     (when (setq window (or best-window second-best-window))
-      (window--display-buffer buffer window 'reuse))))
+      (window--display-buffer buffer window 'reuse alist))))
 
 (defun display-buffer-use-some-window (buffer alist)
   "Display BUFFER in an existing window.
@@ -5653,7 +5711,7 @@
 	      (get-largest-window 0 not-this-window))))
     (when (window-live-p window)
       (prog1
-	  (window--display-buffer buffer window 'reuse)
+	  (window--display-buffer buffer window 'reuse alist)
 	(window--even-window-heights window)
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame (window-frame window)))))))
@@ -5923,6 +5981,97 @@
 			     window))))
 
 ;;; Resizing buffers to fit their contents exactly.
+(defcustom fit-frame-to-buffer nil
+  "Non-nil means `fit-window-to-buffer' can resize frames.
+A frame can be resized if and only if its root window is a live
+window.  The height of the root window is subject to the values
+of `fit-frame-to-buffer-max-height' and `window-min-height'."
+  :type 'boolean
+  :version "24.2"
+  :group 'help)
+
+(defcustom fit-frame-to-buffer-bottom-margin 4
+  "Bottom margin for `fit-frame-to-buffer'.
+This is the number of lines `fit-frame-to-buffer' leaves free at the
+bottom of the display in order to not obscure the system task bar."
+  :type 'integer
+  :version "24.2"
+  :group 'windows)
+
+(defun fit-frame-to-buffer (&optional frame max-height min-height)
+  "Adjust height of FRAME to display its buffer's contents exactly.
+FRAME can be any live frame and defaults to the selected one.
+
+Optional argument MAX-HEIGHT specifies the maximum height of
+FRAME and defaults to the height of the display below the current
+top line of FRAME minus FIT-FRAME-TO-BUFFER-BOTTOM-MARGIN.
+Optional argument MIN-HEIGHT specifies the minimum height of
+FRAME."
+  (interactive)
+  (setq frame (window-normalize-frame frame))
+  (let* ((root (frame-root-window frame))
+	 (frame-min-height
+	  (+ (- (frame-height frame) (window-total-size root))
+	     window-min-height))
+	 (frame-top (frame-parameter frame 'top))
+	 (top (if (consp frame-top)
+		  (funcall (car frame-top) (cadr frame-top))
+		frame-top))
+	 (frame-max-height
+	  (- (/ (- (x-display-pixel-height frame) top)
+		(frame-char-height frame))
+	     fit-frame-to-buffer-bottom-margin))
+	 (compensate 0)
+	 delta)
+    (when (and (window-live-p root) (not (window-size-fixed-p root)))
+      (with-selected-window root
+	(cond
+	 ((not max-height)
+	  (setq max-height frame-max-height))
+	 ((numberp max-height)
+	  (setq max-height (min max-height frame-max-height)))
+	 (t
+	  (error "%s is an invalid maximum height" max-height)))
+	(cond
+	 ((not min-height)
+	  (setq min-height frame-min-height))
+	 ((numberp min-height)
+	  (setq min-height (min min-height frame-min-height)))
+	 (t
+	  (error "%s is an invalid minimum height" min-height)))
+	;; When tool-bar-mode is enabled and we have just created a new
+	;; frame, reserve lines for toolbar resizing.  This is needed
+	;; because for reasons unknown to me Emacs (1) reserves one line
+	;; for the toolbar when making the initial frame and toolbars
+	;; are enabled, and (2) later adds the remaining lines needed.
+	;; Our code runs IN BETWEEN (1) and (2).  YMMV when you're on a
+	;; system that behaves differently.
+	(let ((quit-restore (window-parameter root 'quit-restore))
+	      (lines (tool-bar-lines-needed frame)))
+	  (when (and quit-restore (eq (car quit-restore) 'frame)
+		     (not (zerop lines)))
+	    (setq compensate (1- lines))))
+	(message "%s" compensate)
+	(setq delta
+	      ;; Always count a final newline - we don't do any
+	      ;; post-processing, so let's play safe.
+	      (+ (count-screen-lines nil nil t)
+		 (- (window-body-size))
+		 compensate)))
+      ;; Move away from final newline.
+      (when (and (eobp) (bolp) (not (bobp)))
+	(set-window-point root (line-beginning-position 0)))
+      (set-window-start root (point-min))
+      (set-window-vscroll root 0)
+      (condition-case nil
+	  (set-frame-height
+	   frame
+	   (min (max (+ (frame-height frame) delta)
+		     min-height)
+		max-height))
+	(error (setq delta nil))))
+    delta))
+
 (defun fit-window-to-buffer (&optional window max-height min-height)
   "Adjust height of WINDOW to display its buffer's contents exactly.
 WINDOW must be a live window and defaults to the selected one.
@@ -5943,9 +6092,12 @@
 WINDOW was scrolled."
   (interactive)
   (setq window (window-normalize-window window t))
-  ;; Can't resize a full height or fixed-size window.
-  (unless (or (window-size-fixed-p window)
-	      (window-full-height-p window))
+  (cond
+   ((window-size-fixed-p window))
+   ((window-full-height-p window)
+    (when fit-frame-to-buffer
+      (fit-frame-to-buffer (window-frame window))))
+   (t
     (with-selected-window window
       (let* ((height (window-total-size))
 	     (min-height
@@ -5961,7 +6113,7 @@
 		  ;; Can't get larger than height of frame.
 		  (min max-height
 		       (window-total-size (frame-root-window window)))
-		;, Don't delete other windows.
+		;; Don't delete other windows.
 		(+ height (window-max-delta nil nil window))))
 	     ;; Make `desired-height' the height necessary to show
 	     ;; all of WINDOW's buffer, constrained by MIN-HEIGHT
@@ -6024,89 +6176,7 @@
 		  (window-resize window 1 nil window)
 		  (setq desired-height (1+ desired-height)))))
 	  (error (setq delta nil)))
-	delta))))
-
-(defcustom fit-frame-to-buffer-bottom-margin 4
-  "Bottom margin for `fit-frame-to-buffer'.
-This is the number of lines `fit-frame-to-buffer' leaves free at the
-bottom of the display in order to not obscure the system task bar."
-  :type 'integer
-  :version "24.2"
-  :group 'windows)
-
-(defun fit-frame-to-buffer (&optional frame max-height min-height)
-  "Adjust height of FRAME to display its buffer's contents exactly.
-FRAME can be any live frame and defaults to the selected one.
-
-Optional argument MAX-HEIGHT specifies the maximum height of
-FRAME and defaults to the height of the display below the current
-top line of FRAME minus FIT-FRAME-TO-BUFFER-BOTTOM-MARGIN.
-Optional argument MIN-HEIGHT specifies the minimum height of
-FRAME."
-  (interactive)
-  (setq frame (window-normalize-frame frame))
-  (let* ((root (frame-root-window frame))
-	 (frame-min-height
-	  (+ (- (frame-height frame) (window-total-size root))
-	     window-min-height))
-	 (frame-top (frame-parameter frame 'top))
-	 (top (if (consp frame-top)
-		  (funcall (car frame-top) (cadr frame-top))
-		frame-top))
-	 (frame-max-height
-	  (- (/ (- (x-display-pixel-height frame) top)
-		(frame-char-height frame))
-	     fit-frame-to-buffer-bottom-margin))
-	 (compensate 0)
-	 delta)
-    (when (and (window-live-p root) (not (window-size-fixed-p root)))
-      (with-selected-window root
-	(cond
-	 ((not max-height)
-	  (setq max-height frame-max-height))
-	 ((numberp max-height)
-	  (setq max-height (min max-height frame-max-height)))
-	 (t
-	  (error "%s is an invalid maximum height" max-height)))
-	(cond
-	 ((not min-height)
-	  (setq min-height frame-min-height))
-	 ((numberp min-height)
-	  (setq min-height (min min-height frame-min-height)))
-	 (t
-	  (error "%s is an invalid minimum height" min-height)))
-	;; When tool-bar-mode is enabled and we have just created a new
-	;; frame, reserve lines for toolbar resizing.  This is needed
-	;; because for reasons unknown to me Emacs (1) reserves one line
-	;; for the toolbar when making the initial frame and toolbars
-	;; are enabled, and (2) later adds the remaining lines needed.
-	;; Our code runs IN BETWEEN (1) and (2).  YMMV when you're on a
-	;; system that behaves differently.
-	(let ((quit-restore (window-parameter root 'quit-restore))
-	      (lines (tool-bar-lines-needed frame)))
-	  (when (and quit-restore (eq (car quit-restore) 'frame)
-		     (not (zerop lines)))
-	    (setq compensate (1- lines))))
-	(message "%s" compensate)
-	(setq delta
-	      ;; Always count a final newline - we don't do any
-	      ;; post-processing, so let's play safe.
-	      (+ (count-screen-lines nil nil t)
-		 (- (window-body-size))
-		 compensate)))
-      ;; Move away from final newline.
-      (when (and (eobp) (bolp) (not (bobp)))
-	(set-window-point root (line-beginning-position 0)))
-      (set-window-start root (point-min))
-      (set-window-vscroll root 0)
-      (condition-case nil
-	  (set-frame-height
-	   frame
-	   (min (max (+ (frame-height frame) delta)
-		     min-height)
-		max-height))
-	(error (setq delta nil))))
-    delta))
+	delta)))))
 
 (defun window-safely-shrinkable-p (&optional window)
   "Return t if WINDOW can be shrunk without shrinking other windows.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-09-25 07:01:52 +0000
+++ src/ChangeLog	2012-09-28 09:10:58 +0000
@@ -1,3 +1,8 @@
+2012-09-28  Martin Rudalics  <rudalics@gmx.at>
+
+	* window.c (Vwindow_combination_limit): New default value.
+	(Qwindow_size): New symbol replacing Qtemp_buffer_resize.
+
 2012-09-25  Eli Zaretskii  <eliz@gnu.org>
 
 	* character.c (char_string, string_char): Remove calls to

=== modified file 'src/window.c'
--- src/window.c	2012-09-23 08:44:20 +0000
+++ src/window.c	2012-09-28 08:57:02 +0000
@@ -60,7 +60,7 @@
 static Lisp_Object Qreplace_buffer_in_windows, Qget_mru_window;
 static Lisp_Object Qwindow_resize_root_window, Qwindow_resize_root_window_vertically;
 static Lisp_Object Qscroll_up, Qscroll_down, Qscroll_command;
-static Lisp_Object Qsafe, Qabove, Qbelow, Qtemp_buffer_resize, Qclone_of;
+static Lisp_Object Qsafe, Qabove, Qbelow, Qwindow_size, Qclone_of;
 
 static int displayed_window_lines (struct window *);
 static int count_windows (struct window *);
@@ -6704,7 +6704,7 @@
   DEFSYM (Qreplace_buffer_in_windows, "replace-buffer-in-windows");
   DEFSYM (Qrecord_window_buffer, "record-window-buffer");
   DEFSYM (Qget_mru_window, "get-mru-window");
-  DEFSYM (Qtemp_buffer_resize, "temp-buffer-resize");
+  DEFSYM (Qwindow_size, "window-size");
   DEFSYM (Qtemp_buffer_show_hook, "temp-buffer-show-hook");
   DEFSYM (Qabove, "above");
   DEFSYM (Qbelow, "below");
@@ -6807,16 +6807,16 @@
     window has no parent window or the window shall become a combination
     orthogonal to the one it is part of.
 
-`temp-buffer-resize' means that splitting a window for displaying a
-    temporary buffer makes a new parent window provided
-    `temp-buffer-resize-mode' is enabled.  Otherwise, this value is
-    handled like nil.
+`window-size' means that splitting a window for displaying a buffer
+    makes a new parent window provided `display-buffer' is supposed to
+    explicitly the window's size due to the presence of a
+    `window-height' or `window-width' entry in the alist used by
+    `display-buffer'.  Otherwise, this value is handled like nil.
 
 `temp-buffer' means that splitting a window for displaying a temporary
     buffer always makes a new parent window.  Otherwise, this value is
     handled like nil.
 
-
 `display-buffer' means that splitting a window for displaying a buffer
     always makes a new parent window.  Since temporary buffers are
     displayed by the function `display-buffer', this value is stronger
@@ -6829,7 +6829,7 @@
     sibling.
 
 Other values are reserved for future use.  */);
-  Vwindow_combination_limit = Qtemp_buffer_resize;
+  Vwindow_combination_limit = Qwindow_size;
 
   DEFVAR_LISP ("window-persistent-parameters", Vwindow_persistent_parameters,
 	       doc: /* Alist of persistent window parameters.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> I attach a patch which should do that, in principle (actually
> I just revived the respective part from my old specifiers approach).

Thank you!  I'm starting to test your patch, and I see no problems,
everything works fine, it fixes all regressions in Dired.

> Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a
> corresponding entry to `display-buffer-alist' as you proposed earlier.

This means that `dired-shrink-to-fit' could be marked obsolete?

> (Someone would have to formulate that for users nicely and in the
> appropriate context.)

This text could be written to the CURRENT-NAME arg of `make-obsolete'.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> I attach a patch which should do that, in principle (actually
 >> I just revived the respective part from my old specifiers approach).
 >
 > Thank you!  I'm starting to test your patch, and I see no problems,
 > everything works fine, it fixes all regressions in Dired.

Installed.

 >> Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a
 >> corresponding entry to `display-buffer-alist' as you proposed earlier.
 >
 > This means that `dired-shrink-to-fit' could be marked obsolete?

I think so.

 >> (Someone would have to formulate that for users nicely and in the
 >> appropriate context.)
 >
 > This text could be written to the CURRENT-NAME arg of `make-obsolete'.

Do we support multiline strings in `make-obsolete'?

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

> Installed.

Thanks, I'm happily marking bug#1806 as done :-)

> Do we support multiline strings in `make-obsolete'?

I believe both `make-obsolete' (that could be used for
`dired-pop-to-buffer') and `make-obsolete-variable' (for
`dired-shrink-to-fit') support multiline strings.

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>>> Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a
>>> corresponding entry to `display-buffer-alist' as you proposed earlier.
>>
>> This means that `dired-shrink-to-fit' could be marked obsolete?
>
> I think so.
>
>>> (Someone would have to formulate that for users nicely and in the
>>> appropriate context.)

Do you think this is a good formulation:

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2012-09-30 12:11:18 +0000
+++ lisp/dired.el	2012-10-03 23:28:07 +0000
@@ -248,6 +248,10 @@ (defvar dired-shrink-to-fit t
 ;; I see no reason ever to make this nil -- rms.
 ;;  (> baud-rate search-slow-speed)
   "Non-nil means Dired shrinks the display buffer to fit the marked files.")
+(make-obsolete-variable 'dired-shrink-to-fit
+			"use the Customization interface to add a new rule
+to `display-buffer-alist' where condition regexp is \"Marked Files\",
+action argument symbol is `window-height' and its value is nil." "24.3")
 
 (defvar dired-file-version-alist)
 
@@ -2940,6 +2943,7 @@ (defun dired-mark-prompt (arg files)
 
 (defun dired-pop-to-buffer (buf)
   "Pop up buffer BUF in a way suitable for Dired."
+  (declare (obsolete dired-mark-pop-up "24.3"))
   (let ((split-window-preferred-function
 	 (lambda (window)
 	   (or (and (let ((split-height-threshold 0))
@@ -2981,6 +2985,11 @@ (defun dired-mark-pop-up (buffer-or-name
 window is not shown if there is just one file, `dired-no-confirm'
 is t, or OP-SYMBOL is a member of the list in `dired-no-confirm'.
 
+By default Dired shrinks the display buffer to fit the marked files.
+To disable this, use the Customization interface to add a new rule
+to `display-buffer-alist' where condition regexp is \"Marked Files\",
+action argument symbol is `window-height' and its value is nil.
+
 FILES is the list of marked files.  It can also be (t FILENAME)
 in the case of one marked file, to distinguish that from using
 just the current file.



PS: Also I noticed that there are no new actions in the Customization
interface for `display-buffer-alist'.  I guess you omitted the action
`display-buffer-at-bottom' because it's not yet ready for prime time.
But is there a reason to not add `display-buffer-below-selected' to
`display-buffer--action-function-custom-type'?

bug#1806: dired-pop-to-buffer in wrong place

[Drew Adams]

> +  (declare (obsolete dired-mark-pop-up "24.3"))

Huh?  Are you kidding?  I certainly hope so.

We just spent a long time fixing bug #7533 - it took two years to get it fixed
right.  `dired-mark-pop-up' now works as it should.

Please do not even think about deprecating `dired-mark-pop-up'.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> +  (declare (obsolete dired-mark-pop-up "24.3"))
 >
 > Huh?  Are you kidding?  I certainly hope so.
 >
 > We just spent a long time fixing bug #7533 - it took two years to get it fixed
 > right.  `dired-mark-pop-up' now works as it should.
 >
 > Please do not even think about deprecating `dired-mark-pop-up'.

Don't worry.  This is a `declare' form for `dired-pop-to-buffer' telling
people to use `dired-mark-pop-up' instead.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Drew Adams]

> Don't worry.  This is a `declare' form for 
> `dired-pop-to-buffer' telling
> people to use `dired-mark-pop-up' instead.

Very sorry.  I wondered why it was together with the `dired-pop-to-buffer'
defun.  I didn't understand and jumped to a wrong conclusion.  Thanks, and
again, sorry.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > Do you think this is a good formulation:
 >
 > === modified file 'lisp/dired.el'
 > --- lisp/dired.el	2012-09-30 12:11:18 +0000
 > +++ lisp/dired.el	2012-10-03 23:28:07 +0000
 > @@ -248,6 +248,10 @@ (defvar dired-shrink-to-fit t
 >  ;; I see no reason ever to make this nil -- rms.
 >  ;;  (> baud-rate search-slow-speed)
 >    "Non-nil means Dired shrinks the display buffer to fit the marked files.")
 > +(make-obsolete-variable 'dired-shrink-to-fit
 > +			"use the Customization interface to add a new rule
 > +to `display-buffer-alist' where condition regexp is \"Marked Files\",
 > +action argument symbol is `window-height' and its value is nil." "24.3")

I think it's OK.  Though we should decide generally whether we (1) want
an exact match for such buffers (that is, including space and asterisks)
and (2) whether obsoletion strings can be that long (I have not found
any when I searched recently).

 >  (defvar dired-file-version-alist)
 >
 > @@ -2940,6 +2943,7 @@ (defun dired-mark-prompt (arg files)
 >
 >  (defun dired-pop-to-buffer (buf)
 >    "Pop up buffer BUF in a way suitable for Dired."
 > +  (declare (obsolete dired-mark-pop-up "24.3"))
 >    (let ((split-window-preferred-function
 >  	 (lambda (window)
 >  	   (or (and (let ((split-height-threshold 0))
 > @@ -2981,6 +2985,11 @@ (defun dired-mark-pop-up (buffer-or-name
 >  window is not shown if there is just one file, `dired-no-confirm'
 >  is t, or OP-SYMBOL is a member of the list in `dired-no-confirm'.
 >
 > +By default Dired shrinks the display buffer to fit the marked files.
 > +To disable this, use the Customization interface to add a new rule
 > +to `display-buffer-alist' where condition regexp is \"Marked Files\",
 > +action argument symbol is `window-height' and its value is nil.
 > +
 >  FILES is the list of marked files.  It can also be (t FILENAME)
 >  in the case of one marked file, to distinguish that from using
 >  just the current file.

We should add the detailed code somewhere, probably to the Elisp manual.
As an example, I didn't know that using an ACTION argument where the
FUNCTION component is nil would work in the first place.

 > PS: Also I noticed that there are no new actions in the Customization
 > interface for `display-buffer-alist'.  I guess you omitted the action
 > `display-buffer-at-bottom' because it's not yet ready for prime time.
 > But is there a reason to not add `display-buffer-below-selected' to
 > `display-buffer--action-function-custom-type'?

No.  I didn't recall that option any more (although I must have done so
earlier because I added `display-buffer-in-previous-window' to it).

There are further issues.

(1) Document alist entries like `window-height' and `window-width'
somehwere without blowing up the doc-string of `display-buffer'.

(2) Decide whether and how we can use `window-height' and `window-width'
to replace `split-height-threshold' and `split-width-threshold'.  Or
maybe find some other substitute.

(3) Include alist entries to specify a minimum height/width for a window
to reuse (there's a request for such a feature in a bug report).

(4) As soon as we switch to pixel sizes allow to specify all these
options in terms of pixels too.

(5) Handle the delayed evaluation of `fit-window-to-buffer' in
`vc-diff-finish' somehow.  Currently, we can't pass this to
`display-buffer' because we don't know the final size of the buffer when
we call it.  So this means that we have to find out whether
`display-buffer' would have called `fit-window-to-buffer' in the first
place and, if so, call `fit-window-to-buffer' when we know the final
buffer size.  Tedious to do.

(6) Related: Move `display-buffer-mark-dedicated' to the alists.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juri Linkov]

>> +(make-obsolete-variable 'dired-shrink-to-fit
>> +			"use the Customization interface to add a new rule
>> +to `display-buffer-alist' where condition regexp is \"Marked Files\",
>> +action argument symbol is `window-height' and its value is nil." "24.3")
>
> I think it's OK.  Though we should decide generally whether we (1) want
> an exact match for such buffers (that is, including space and asterisks)

In the Customization UI it would be simple to type a regexp without
special characters.  OTOH, the user will be able to copy the exact match
from the docstring, so we could add the exact match to docstrings:

(make-obsolete-variable 'dired-shrink-to-fit
			"use the Customization interface to add a new rule
to `display-buffer-alist' where condition regexp is \"^ \\*Marked Files\\*$\",
action argument symbol is `window-height' and its value is nil." "24.3")

> and (2) whether obsoletion strings can be that long (I have not found
> any when I searched recently).

Just try to evaluate this `make-obsolete-variable' and see its result
in `C-h v dired-shrink-to-fit RET'.

> We should add the detailed code somewhere, probably to the Elisp manual.
> As an example, I didn't know that using an ACTION argument where the
> FUNCTION component is nil would work in the first place.

I learned about this feature from Stefan's comment in
http://debbugs.gnu.org/3419#133

> There are further issues.

Let's discuss them on emacs-devel.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 > In the Customization UI it would be simple to type a regexp without
 > special characters.  OTOH, the user will be able to copy the exact match
 > from the docstring, so we could add the exact match to docstrings:
 >
 > (make-obsolete-variable 'dired-shrink-to-fit
 > 			"use the Customization interface to add a new rule
 > to `display-buffer-alist' where condition regexp is \"^ \\*Marked Files\\*$\",
 > action argument symbol is `window-height' and its value is nil." "24.3")

Good.

 >> and (2) whether obsoletion strings can be that long (I have not found
 >> any when I searched recently).
 >
 > Just try to evaluate this `make-obsolete-variable' and see its result
 > in `C-h v dired-shrink-to-fit RET'.

You're right.  So please install them.

 >> We should add the detailed code somewhere, probably to the Elisp manual.
 >> As an example, I didn't know that using an ACTION argument where the
 >> FUNCTION component is nil would work in the first place.
 >
 > I learned about this feature from Stefan's comment in
 > http://debbugs.gnu.org/3419#133

I see.  BTW, this bug must have been swept under my carpet.  Though the
"reuse window & resize it" part should have been fixed by now.  I'll
close it ;-)

 >> There are further issues.
 >
 > Let's discuss them on emacs-devel.

OK

Thanks, martin

bug#1806: dired-pop-to-buffer in wrong place

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Note that I have added an option `temp-buffer-resize-regexps' which can
> be used to turn off resizing in selected buffers.

What is the rationale for this change?  I can't find any discussion
about this on emacs-devel or the bug list, but maybe I missed it.

I'm not enthusiastic about the existence of temp-buffer-resize-mode in
the first place.  It's a bad concept, since it creates a difference
between "temporary buffers" and other kinds of buffers displayed via
display-buffer.  But there are no guidelines for when such a difference
should exist.  So adding more knobs onto temp-buffer-resize-mode is a
step in the wrong direction, IMO.

bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

 >> Note that I have added an option `temp-buffer-resize-regexps' which can
 >> be used to turn off resizing in selected buffers.
 >
 > What is the rationale for this change?  I can't find any discussion
 > about this on emacs-devel or the bug list, but maybe I missed it.

The problem has been discussed in the thread for bug#1806 and in a
thread you started about window shrinking via VC-diff.  There it has
been asked for a way to switch off auto-resizing.  My rationale is to do
all `fit-window-to-buffer' stuff under `temp-buffer-resize-mode' and
allow tweaking this in a uniform manner for individual buffers.

 > I'm not enthusiastic about the existence of temp-buffer-resize-mode in
 > the first place.  It's a bad concept, since it creates a difference
 > between "temporary buffers" and other kinds of buffers displayed via
 > display-buffer.

Then we probably should change that concept.  My intention was to fit
windows even when `display-buffer' is not called.  For example, after
certain changes of the buffer contents, without asking for a redisplay
via `display-buffer'.

 > But there are no guidelines for when such a difference
 > should exist.  So adding more knobs onto temp-buffer-resize-mode is a
 > step in the wrong direction, IMO.

I have no opinion on this and can do whatever people want.  But bug#1806
should be eventually closed in some way.

martin

bug#1806: dired-pop-to-buffer in wrong place

[Juanma Barranquero]

On Wed, Sep 26, 2012 at 10:48 AM, martin rudalics <rudalics@gmx.at> wrote:

> Then we probably should change that concept.  My intention was to fit
> windows even when `display-buffer' is not called.  For example, after
> certain changes of the buffer contents, without asking for a redisplay
> via `display-buffer'.

FWIW, I enthusiastically support any way to make temporary windows
resize automa[tg]ically to fit the buffer.

    Juanma