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: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, 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: Sat, 09 Feb 2013 10:22:28 +0100

> 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

Previous Next

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