bug#6204: vc-dir always splits the frame

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> So we apparently want to support options like `pop-up-windows' and
> `pop-up-frames' forever.

For the foreseeable future, at least, yes.

> Shall applications continue to bind `pop-up-windows' and `pop-up-frames'
> as they do now?  I suppose where they do now they should use (1) or (3)
> instead.

Exactly, they should use (3) or (1) depending on whether it is based on
some impression that it would be a better default for this particular
case, or whether it's in response to a specific user request
(e.g. calling find-file-other-window rather than find-file).

BTW, I'd be happy to get rid of all the foobar-other-window and
foobar-other-frame and instead provide new prefix commands that affect
the behavior of the next command, so instead of C-x 4 f, you'd do
something like C-x 4 and then C-x C-f.  We would probably then add some
special hack to make C-x 4 f still work as before.

>> Some of the intention behind the `default-params' would be to get rid of
>> calls to switch-to-buffer (replaced by calls to pop-to-buffer with
>> a same-window default-param).  Such cases already disregard
>> pop-up-windows and pop-up-frames, so ignoring them w.r.t default-params
>> would be consistent with such a case.
> You mean all cases where the buffer argument of `switch-to-buffer' names
> an existing buffer (probably all of them do, but I didn't check).

I mean all the calls to switch-to-buffer in Elisp code where the author
obviously didn't take into account the fact that there can be
minibuffer-only frames, or that the selected window can be dedicated,
etc...
IOW put switch-to-buffer in byte-compile-interactive-only-functions
which we currently can't do because we don't have a good replacement
for it yet.


        Stefan