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

[martin rudalics <rudalics@gmx.at>]

 >> That's one possibility, yes.  Tho adding an argument doesn't sound
 >> much fun.  So I'd prefer if it could be passed via ACTION.
 >
 > I have read this bug thread again. I am confused by this decision. Why
 > do we want to tell display-buffer to do nothing (via ACTION or extra
 > arg) when we can choose not to call it? Isn't not calling it better?

Stefan proposes to handle the case where the application wants to
display the buffer but `display-buffer' is not able to do so.  Ever
since, all callers of `display-buffer' I know of silently assumed that
the latter would display the buffer and return its window despite the
fact that it was possible that the buffer would not get displayed.

Stefan's proposal would correct that misunderstanding although now these
might result from the fact that if no argument is "passed via ACTION",
`display-buffer' could use the selected window, harming an application's
assumptions provided via setting inhibit-same-window to non-nil.  We at
least would have to document such fact but it's an "incompatible change"
nevertheless.  I think this is a minor evil and should be fairly rare as
well.

Now if an application and/or user do not want to display the buffer in
the first case, `display-buffer' should not be called.  If, however, the
call cannot be avoided, we should add a second (user) action which
avoids entering the loop in `display-buffer' and returns nil immediately
provided the first action was set (that is, the calling application at
least pretends to know how to handle a nil return value).

martin