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?