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

[martin rudalics]

> No, I really meant a window that's not displayed, not the root-window.
> E.g. a window on a separate frame with the frame marked invisible.

I'm currently investigating this idea when fitting a frame to a buffer
before the frame is displayed at all.  But I wouldn't recommend it in
the context of the present thread - any calls to `display-buffer' should
provide some visual feedback.

In principle, `display-buffer' could always return a window, reusing a
dedicated one or making a new frame, if necessary.  OTOH, the while loop
in `display-buffer' could easily give up when one of the functions it
calls returns a special value, say 'skip, and return nil in that case.

The problem is how to make callers of `display-buffer' (and more
seriously `pop-to-buffer' and `switch-to-buffer') aware of the fact that
no window was found, maybe deliberately.

I think the only correct solution is to have the caller add an alist
entry (or an extra argument to `display-buffer') say 'may-fail, whose
semantics are:

- If 'may-fail is non-nil, allow returning a nil value - I, the caller,
  already know how to handle that.

- If 'may-fail is nil or doesn't exist, return some window at any cost.

martin