RE: customize-*-other-window cmds don't respect special-display*values

[Drew Adams]

    > What in the name "-other-window" indicates that the particular way the
    > function displays the buffer should override those particular
    > settings? What are the particular instructions included in the
    > "other-window" name/license.

    The ``other window'' part?  It means that the buffer will be displayed
    in the window that we call in Emacs ``the other window''.  Since the
    window to display is thus fixed, special-display-regexps and its ilk
    cannot be applied, because they would change the window where the
    buffer will be displayed.

    Does that make sense?

Not to me.

First, I'm not so sure that the name "other-window" always denotes the same
thing in Emacs. And the "other-window" is certainly not always a "fixed"
window, if by fixed you mean the same window. The function `other-window',
for instance, can itself return any number of different "other" windows.

More important than debating the proper meaning of "other-window" in general
or even as part of an arbitrary function name, however, is the case at hand:
should these `customize*-other-window' functions nullify
`special-display-regexps'? What should the "other-window" in _their_ names
imply in terms of behavior?

I have `pop-up-frames' non-nil, so "other-window" functions always open
another frame - standard Emacs (`display-buffer') behavior. There is nothing
fixed about "other-window" in this case, certainly. (And that's the case I'm
most concerned about.)

There are lots of "other-window" functions in Emacs (more than 50, that I
see in emacs -q), and _none_ of the others monkeys around with
`special-display*' in this way (none that I have found, at least). So your
"fixed" rule has exception as its own rule.

Many such functions just call `switch-to-buffer-other-window'. And that just
binds `pop-up-windows' to t and calls `pop-to-buffer' with the
insist-on-another-window option (_an_ other, not _the_ other). With
`pop-up-frames' non-nil, this just opens a new frame (a la
`display-buffer') - there is nothing sacred or fixed about "other-window" in
that case, that I can see.

And there is nothing to suggest that `special-display-regexps' should be
nullified in that case, either.

Of course, we could alternatively decide, in the name of fixity, to change
`pop-to-buffer' et al to fit your fixed other-window description, so that
their "ilk cannot be applied" with `pop-up-frames' non-nil, "because they
change the window where the buffer will be displayed."