[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]