bug#13594: 24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN

[Juri Linkov]

> It's a valid return value, but only when display-buffer is *unable to
> display the buffer*.  It is *very* rare to be unable to do so.  E.g. it
> will never happen unless at least one of pop-up-frame-function or
> display-buffer-fallback-action is changed.

Trying to do (setq display-buffer-fallback-action nil)
and `M-x compile RET' goes to re-arrange the wrong window
(that displays "*scratch*" in `emacs -Q') because the nil WINDOW arg
of `set-window-start' defaults to the selected window,  so yes,
a nil value is not a good thing to return from display-buffer.

> Maybe a way around that is to use a special window that's never
> displayed.  But that might introduce more trouble than it's trying
> to solve.

Trying to use an internal window:

(add-to-list 'display-buffer-alist '("\\*compilation\\*" display-buffer-ignore 
(nil)))
(defun display-buffer-ignore (&rest _ignore) (frame-root-window))

fails with `(wrong-type-argument window-live-p #<window 0x286f258>)',
so this is not possible to do without changes to the window framework
to add a new window type for live hidden windows.