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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> -    (setq outwin (display-buffer outbuf))
> +    (setq outwin (display-buffer outbuf)) ; Note: OUTWIN may be nil

`display-buffer' says:

   Return the window chosen for displaying BUFFER-OR-NAME,
   or nil if no such window is found.

which mostly means that it only returns nil if it couldn't find any
window to display the buffer, which is exceedingly rare.  Most/all
callers assume that display-buffer will display the buffer somewhere
(they sometimes disregard to return value, but when they don't they
almost systematically assume the return value is non-nil).

If you look further in the docstring you'll also see:

   Then it calls each function in the combined function list in turn,
   passing the buffer as the first argument and the combined alist as
   the second argument, until one of the functions returns non-nil.

Which again hints at the fact that nil is not treated as a valid return
value of display-buffer except when everything else failed.

IOW returning nil from display-buffer will inevitably bump into bugs.
Generally if you don't want to display a buffer, the best way to do that
is by not calling display-buffer.

So maybe the best approach is to extend compile.el such that it can be
told to do its job without displaying the compilation buffer.  If you do
that, try to take into account that this usage pattern could be useful
in other contexts than ggtags.el, for example users might prefer to not
see the compilation buffer and just be moved to the first error
automatically, and have C-x ` output the error message in the echo area
(maybe, accompanied by the number of errors left).


        Stefan