bug#9532: 24.0.50; `special-display-regexps' is no longer respected

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> So, you agree to the incompatibility for the non-interactive case?  That
>> is to say, a non-interactive call to switch-to-buffer (and ONLY a
>> non-interactive call) will now trigger special display.  Previously, in
>> Emacs 23, it would use the selected window.

Yes.

> It just occurred to me that it would be safer to leave switch-to-buffer
> unchanged, and instead reinstate pop-to-buffer-same-window specifically
> for the callers in question, i.e. the callers who used the
> same-window-regexps/display-buffer trick.  pop-to-buffer-same-window
> would raise a special window for special buffers, instead of using the
> selected window; s-t-b would use the selected window, as in Emacs 23.

It would also be a change in behavior since same-window-* took
precedence over special-display-*.  But it would be a good change: users
like Drew (and myself) had to set same-window-* to nil to let
special-display-* do its job.

So I agree those callers who used same-window-* should be changed to
obey special-display-*, as for whether callers of switch-to-buffer
should also obey special-display-* (and/or display-buffer-alist) I don't
know for sure.

Basically w.r.t "same-window behavior" we have 3 options:
1- never touch another window.
2- obey special-display-* and display-buffer-alist.
3- use the selected window if at all possible, but fallback to
   pop-to-buffer instead of signalling an error.
The third is the current behavior of interactive uses of switch-to-buffer.
The second is the behavior we want for former users of same-window-*.
The third is the behavior that corresponds to Emacs-23's switch-to-buffer.
We could shoehorn this into the `force-same-window' argument of
switch-to-buffer, but I'm not convinced that the difference between
options 2 and 3 is worth the trouble.
  

        Stefan