From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: patch gud-gdb to respect other-frame-window? Date: Mon, 30 Jul 2018 11:49:12 -0500 Message-ID: <868t5sr7nb.fsf@stephe-leake.org> References: <86muuaq7m8.fsf@stephe-leake.org> <83fu02q797.fsf@gnu.org> <86in4xqkit.fsf@stephe-leake.org> <5B5EBF82.1020701@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1532970269 8282 195.159.176.226 (30 Jul 2018 17:04:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jul 2018 17:04:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 30 19:04:25 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fkBar-00021e-9D for ged-emacs-devel@m.gmane.org; Mon, 30 Jul 2018 19:04:25 +0200 Original-Received: from localhost ([::1]:53857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkBcx-0003i7-Tf for ged-emacs-devel@m.gmane.org; Mon, 30 Jul 2018 13:06:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkBMF-0005Ns-RV for emacs-devel@gnu.org; Mon, 30 Jul 2018 12:49:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkBMC-0003dp-Et for emacs-devel@gnu.org; Mon, 30 Jul 2018 12:49:19 -0400 Original-Received: from smtp97.ord1d.emailsrvr.com ([184.106.54.97]:39895) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fkBMC-0003dK-92 for emacs-devel@gnu.org; Mon, 30 Jul 2018 12:49:16 -0400 Original-Received: from smtp13.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 9247BC048B for ; Mon, 30 Jul 2018 12:49:14 -0400 (EDT) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp13.relay.ord1d.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 59895C0482 for ; Mon, 30 Jul 2018 12:49:14 -0400 (EDT) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 (76-218-37-33.lightspeed.kscymo.sbcglobal.net [76.218.37.33]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Mon, 30 Jul 2018 12:49:14 -0400 In-Reply-To: <5B5EBF82.1020701@gmx.at> (martin rudalics's message of "Mon, 30 Jul 2018 09:34:26 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 184.106.54.97 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228000 Archived-At: martin rudalics writes: >> Never mind; I realized I can set 'display-buffer-overriding-action' to >> 'display-buffer-same-window in my ~/.emacs; that overrides this code, >> and still lets other-frame-window do its thing. > > Please don't. > > If 'other-frame-window' sets 'display-buffer-overriding-action' > itself, then it should _not_ be overridden by the user. It's not quite that simple. The current design of 'other-frame-window' only defines the behavior when the other-frame or other-window prefixes are invoked; the behavior with no prefix is left to the default Emacs code, or to a user-provided 'display-buffer-overriding-action'. I don't remember if that was a concious decision, but in retrospect it looks like the right one. In more detail, 'other-frame-window' pushes overriding values in front of user-set values in 'display-buffer-overriding-action' when the other-window and other-frame prefixes are invoked, and pops them off when the command is done, leaving the user-set values intact. > It's a simple statement that 'other-frame-window' thinks that it is > always right in its decision and the user has to either take it or > leave it. Not quite; it is only right when the prefixes are invoked. We could change 'other-frame-window' to set the no-prefix 'display-buffer-overriding-action' as well, but I think it is better to leave that to the user; some might like the current Emacs default behavior (I did, until I ran into this gud-gdb behavior). -- -- Stephe