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

Previous Next

Full log

Message #62 received at 13594 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: 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.

martin

Previous Next

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