From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Leo Liu Newsgroups: gmane.emacs.bugs Subject: bug#13594: 24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN Date: Tue, 12 Feb 2013 01:55:08 +0800 Message-ID: References: <87sj5apclq.fsf@mail.jurta.org> <87r4ktoinh.fsf@mail.jurta.org> <87mwvhxehw.fsf@mail.jurta.org> <87zjzfz0nq.fsf@mail.jurta.org> <51161554.9010609@gmx.at> <8738x4o5cp.fsf@mail.jurta.org> <5117D9B5.5090203@gmx.at> <87pq07b4k4.fsf@mail.jurta.org> <51192ADD.9010607@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360605348 14456 80.91.229.3 (11 Feb 2013 17:55:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 17:55:48 +0000 (UTC) Cc: 13594@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 11 18:56:10 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U4xbq-0000Sf-QL for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Feb 2013 18:56:07 +0100 Original-Received: from localhost ([::1]:40240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4xbX-0000IE-CE for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Feb 2013 12:55:47 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4xbS-0000A5-Ey for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 12:55:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4xbR-0007Ze-FO for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 12:55:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4xbR-0007ZY-9x for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 12:55:41 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U4xbl-0008Sz-UQ for bug-gnu-emacs@gnu.org; Mon, 11 Feb 2013 12:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Feb 2013 17:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13594 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 13594-submit@debbugs.gnu.org id=B13594.136060535532533 (code B ref 13594); Mon, 11 Feb 2013 17:56:01 +0000 Original-Received: (at 13594) by debbugs.gnu.org; 11 Feb 2013 17:55:55 +0000 Original-Received: from localhost ([127.0.0.1]:51110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4xbc-0008Se-R5 for submit@debbugs.gnu.org; Mon, 11 Feb 2013 12:55:55 -0500 Original-Received: from mail-pa0-f46.google.com ([209.85.220.46]:44388) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4xbZ-0008SV-Ua for 13594@debbugs.gnu.org; Mon, 11 Feb 2013 12:55:51 -0500 Original-Received: by mail-pa0-f46.google.com with SMTP id kp14so3157733pab.5 for <13594@debbugs.gnu.org>; Mon, 11 Feb 2013 09:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=7volXQ5t2wwReS6zOu3uPDleUuM9Mpe36yJPi4CU70E=; b=eHKvLHgHvHHd/hqGOeSAGHttOaR8Z4qBuh9wKJUBLMe/h9iM8UNh5Rld4pmuclCKd7 dgl5bbXGi8BHn23tLTuJYnZNpTmZ+tgiKMMOPb+j2u85mEjdl6ckapEHxQ4Tk2LCaBOH iYUHTmTWVDLTKqmYFe3R1lvjf9DHShTvBJ1ojLyfMkusTj2HvoUsR3WeP323lKJJuu1P IXP6n+jUjSzuzw1excdsQwBuU/OpjJC8eDB4ad69x93KUOP1idbuDCagzcHz73At7gL1 J0y4GAS7rat0z+rKrs1ROKw7J23OGBxXtxD65qBMCEd9GfxuwZAjOyPx9pJxSPr5U/Bh HTFQ== X-Received: by 10.66.251.129 with SMTP id zk1mr5302853pac.9.1360605327640; Mon, 11 Feb 2013 09:55:27 -0800 (PST) Original-Received: from localhost ([119.161.133.99]) by mx.google.com with ESMTPS id y9sm68187095paw.1.2013.02.11.09.55.20 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 11 Feb 2013 09:55:26 -0800 (PST) Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAGFBMVEUzRVhbQj4eZqO6SjnT eWpxnMetm5b6/PmidmqrAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1F B9cBBwMLBfKABCMAAAFoSURBVCjPtZI9a8MwEIaFoc7aYDdelQMna0Em3tsSr0XUeE2Q6a22a+v+ fk8fSSBkbDUI6dHpfe9OEvRgiD+ApqKPJgJeB6iUUXWESjUe/ig38AJrhqqvaU2nTIXbNvOQ40fe qdry4kyGoVWsfCQalXpHnJGM01wjWdYbMlXNFdsZDO69m9aqNqxEJqTEgbM5OF7wlEfIoll1Ked4 LbM5X2EdILLokEdmI8z7g5cKED0cuTC930TYhy7ZDekkXVGw/L60TguJePPxcJF48lpsSUWEA/Ju jGFNgJOXc4Hz7TmAdBeu5Ve4AEjOi2/2jfd3cAJZ+IbNrvdjgBZY01b+HTuG3cLws6BJZqVOj/pp T0OqVwx3rFq+QmJwx3loK5JSLEhDIt62+mtC2C+SrAUxEbV6C6v2BRbd6pILBKFpepKZJHgGgrKF sptSUUoczpwg2pQ7ZH1tgs0ou/917mzz6Cs2//C978cv5l07L02orIEAAAAASUVORK5CYII= In-Reply-To: <51192ADD.9010607@gmx.at> (martin rudalics's message of "Mon, 11 Feb 2013 18:31:09 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.93 (OS X 10.8.2) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71066 Archived-At: On 2013-02-12 01:31 +0800, martin rudalics wrote: >> 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 What happens if we just return a minibuffer window to display-buffer? (still ugly as hell) Leo