[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: Mon, 11 Feb 2013 18:31:09 +0100

>> Returning the selected window is harmless.
> Only if it displays the requested buffer.

We could make it do that.  That is, even for (inhibit-same-window . t)
and the case where the selected window is dedicated, we could display it
there if we don't have another choice.

> Do you think it is possible to implement a special "hidden" window type
> so callers could operate on it invisibly to the user?

Not really.  If you call `with-selected-window' on such a window and get
stuck in it, the display routines would probably have to find their way
out of such a situation.

We could, as Stefan proposed, use the root window of an invisible frame
for this.  But as I mentioned earlier, this has the disadvantage that
you have to somehow clean up that frame when you delete the last visible
frame.  Officially, `delete-frame' should handle this case but at least
here on Windows XP it certainly doesn't.  And I'm quite sure that we can
find at least one window manager where sampling the visibility of frames
is not 100% reliable.


reply via email to

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