From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#12648: 24.2.50; display-buffer switches to another frame Date: Wed, 17 Oct 2012 11:37:59 +0200 Message-ID: <507E7C77.2020700@gmx.at> References: <83391h5787.fsf@gnu.org> <507B0590.3020402@gmx.at> <83zk3o4zus.fsf@gnu.org> <507C071C.1090402@gmx.at> <83mwzn4pfe.fsf@gnu.org> <507D2B53.7040607@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1350466744 29571 80.91.229.3 (17 Oct 2012 09:39:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 09:39:04 +0000 (UTC) Cc: 12648@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 17 11:39:11 2012 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 1TOQ5n-0004bb-3g for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Oct 2012 11:39:11 +0200 Original-Received: from localhost ([::1]:36086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOQ5g-0005hY-6o for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Oct 2012 05:39:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOQ5Y-0005gr-B7 for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2012 05:39:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOQ5M-0005FE-Lv for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2012 05:38:56 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOQ5M-0005FA-Iu for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2012 05:38:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TOQ6b-0005xd-Qk for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2012 05:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Oct 2012 09:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12648-submit@debbugs.gnu.org id=B12648.135046676822870 (code B ref 12648); Wed, 17 Oct 2012 09:40:01 +0000 Original-Received: (at 12648) by debbugs.gnu.org; 17 Oct 2012 09:39:28 +0000 Original-Received: from localhost ([127.0.0.1]:47720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TOQ63-0005wp-VR for submit@debbugs.gnu.org; Wed, 17 Oct 2012 05:39:28 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:40371) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TOQ61-0005wa-AR for 12648@debbugs.gnu.org; Wed, 17 Oct 2012 05:39:25 -0400 Original-Received: (qmail invoked by alias); 17 Oct 2012 09:38:02 -0000 Original-Received: from 62-47-52-36.adsl.highway.telekom.at (EHLO [62.47.52.36]) [62.47.52.36] by mail.gmx.net (mp016) with SMTP; 17 Oct 2012 11:38:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19tS08CIcJtO1yg4pVOn8QEWis4sdtiw3xBwB3N6r H2lW0cDf5SjnLb In-Reply-To: X-Y-GMX-Trusted: 0 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 (newer, 2) 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:65679 Archived-At: > I'm not sure what is its semantics either, but the problem you're > referring to is specifically when *creating* a new frame, so it > basically means that inhibit-switch-frame can only work reliably if it > prevents creation of new frames. But it might still make a difference > when using an existing frame by preventing that we raise that frame. > Not sure if it will also repvent it from being de-iconified (which > would again risk raising it outside of our control). Looks like a problem with reconciling conflicting values in the `inhibit-switch-frame' (t) and `reusable-frames' (0 or t) entries. martin