From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: switch-to-buffer: for interactive use only Date: Wed, 13 Jul 2011 17:53:14 -0400 Message-ID: <874o2p6e5x.fsf@stupidchicken.com> References: <0aiprg76eu.fsf@fencepost.gnu.org> <4E16A728.5040002@gmx.at> <4E170E48.5040408@gmx.at> <4E173412.3090804@gmx.at> <87d3hkmt0k.fsf@stupidchicken.com> <87vcvcmr8y.fsf@stupidchicken.com> <87zkkokwp7.fsf@stupidchicken.com> <871uxzxnme.fsf@stupidchicken.com> <87vcv8c1d7.fsf@stupidchicken.com> <4E1C078A.5090809@gmx.at> <87vcv6191e.fsf@stupidchicken.com> <4E1DD34A.2040007@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1310594034 24057 80.91.229.12 (13 Jul 2011 21:53:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 21:53:54 +0000 (UTC) Cc: Juanma Barranquero , Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 13 23:53:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh7NK-0005Z0-IQ for ged-emacs-devel@m.gmane.org; Wed, 13 Jul 2011 23:53:46 +0200 Original-Received: from localhost ([::1]:47612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh7NI-0005IY-TT for ged-emacs-devel@m.gmane.org; Wed, 13 Jul 2011 17:53:45 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh7Mx-0005Hh-0q for emacs-devel@gnu.org; Wed, 13 Jul 2011 17:53:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qh7Mu-00067J-PI for emacs-devel@gnu.org; Wed, 13 Jul 2011 17:53:22 -0400 Original-Received: from vm-emlprdomr-03.its.yale.edu ([130.132.50.144]:35263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh7Mu-000675-AJ for emacs-devel@gnu.org; Wed, 13 Jul 2011 17:53:20 -0400 Original-Received: from furball (dhcp128036014059.central.yale.edu [128.36.14.59]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id p6DLrEIS017669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Jul 2011 17:53:14 -0400 In-Reply-To: <4E1DD34A.2040007@gmx.at> (martin rudalics's message of "Wed, 13 Jul 2011 19:18:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.144 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142014 Archived-At: martin rudalics writes: > I think that we want two types of `switch-to-buffer' functions: > > (1) The one where using any window but the selected doesn't make sense. > This seems the case for C-x b and maybe a few other cases. We could > use a `set-window-buffer' based function here and error out if the > selected window is strongly dedicated or the minibuffer window. > Call this function `switch-to-buffer-same-window' and bind C-x b to > it. This function would be marked as not callable from Elisp. > > (2) A function that pops to a buffer, preferably in the selected window. > This is the case for almost all other calls of `switch-to-buffer'. > For this we could rewrite `switch-to-buffer' to call `pop-to-buffer' > with the 'same-window argument and, if Stefan insists, make it reuse > the same window even if it's weakly dedicated. This function would > be callable from Elisp. C-x b is usually called because the user wants to go to another buffer, so if the selected window absolutely can't be used then it's better for the command should intelligently handle it by using another window. As for non-interactive usage, that's addressed by the FORCE-SAME-WINDOW argument. Those callers that want to force selecting the same window specific can use this arg, so we don't need a different function. After discussing with Stefan off-list, I've committed the change to switch-to-buffer that adds the FORCE-SAME-WINDOW argument. I'll get to changing the callers shortly.