From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: switch-to-buffer: for interactive use only Date: Thu, 07 Jul 2011 17:11:56 -0400 Message-ID: References: <0aiprg76eu.fsf@fencepost.gnu.org> <87hb6zt8rg.fsf@stupidchicken.com> <8739ihlsry.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1310074283 11681 80.91.229.12 (7 Jul 2011 21:31:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2011 21:31:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 23:31:18 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 1QewAF-0004yA-IZ for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2011 23:31:15 +0200 Original-Received: from localhost ([::1]:55917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QewAE-0001HP-ES for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2011 17:31:14 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:48281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qevrf-0003mI-Br for emacs-devel@gnu.org; Thu, 07 Jul 2011 17:12:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qevre-0002RT-04 for emacs-devel@gnu.org; Thu, 07 Jul 2011 17:12:03 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:44079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qevra-0002Qf-Bn; Thu, 07 Jul 2011 17:11:58 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p67LBvKH010469; Thu, 7 Jul 2011 17:11:57 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 2E3E7B4177; Thu, 7 Jul 2011 17:11:57 -0400 (EDT) In-Reply-To: <8739ihlsry.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 07 Jul 2011 16:50:25 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3911=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3911> : streams <658565> : uri <909084> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:141752 Archived-At: >>> How would you change this? >> >>> (defun unbury-buffer () >>> "Switch to the last buffer in the buffer list." >>> (interactive) >>> (switch-to-buffer (last-buffer))) >> >> Either using with-no-warnings or using set-window-buffer. > What's wrong with using switch-to-buffer? > If you could elaborate a bit more on what bugs you are referring to when > you say >> Most of those calls were bugs waiting to catch you in Emacs<23 ("you" >> being typically a user like myself who uses dedicated windows and/or >> minibuffer-only frames). > then maybe we could come up with a way to issue the warning more > selectively. Because AFAICT the usage in unbury-buffer, and probably > many other places in Emacs, is completely correct, and I agree with > Glenn that issuing a zillion warnings for this not satisfactory. There are two different uses of switch-to-buffer: - the ones like in unbury-buffer where the main point is that it operates on the selected window. - the ones like in find-file where the main point is that it wants to display a given buffer. In single-frame circumstances, the two cases are identical, so most authors who use Emacs in a single-frame mode don't even realize that there's a choice to be made. Until Emacs-23, switch-to-buffer assumed the main point was to only affect the selected-window (and hence signal an error if the switch is not possible). In Emacs-23, I've changed it to assume that the main point is to display the given buffer (by delegating the job to pop-to-buffer if necessary). Recently, I reverted my Emacs-23 change because it introduced bugs (e.g. in unbury-buffer and bs--cycle-next). Stefan PS: BTW, I think the interactive use of switch-to-buffer is "the second case" (and should hence call pop-to-buffer-same-window).