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