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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: bug#13594: 24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN
Date: Fri, 08 Feb 2013 10:10:17 +0200

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.