From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Jumping to C source from *Help* Date: 13 Apr 2004 14:12:20 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <871xmrg3gu.fsf-monnier+emacs@gnu.org> References: <20040407025556.FCC3.LEKTU@mi.madritel.es> <87wu4rxaki.fsf@mail.jurta.org> <877jwqfmjb.fsf-monnier+emacs@alfajor.local> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081880484 3944 80.91.224.253 (13 Apr 2004 18:21:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2004 18:21:24 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 13 20:21:18 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDSX8-0002YL-00 for ; Tue, 13 Apr 2004 20:21:18 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDSX7-000449-00 for ; Tue, 13 Apr 2004 20:21:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDSVv-0004zd-IO for emacs-devel@quimby.gnus.org; Tue, 13 Apr 2004 14:20:03 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDSP9-0001aY-4O for emacs-devel@gnu.org; Tue, 13 Apr 2004 14:13:03 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDSOZ-0001NC-QX for emacs-devel@gnu.org; Tue, 13 Apr 2004 14:12:59 -0400 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDSOZ-0001Ma-6m; Tue, 13 Apr 2004 14:12:27 -0400 Original-Received: from alfajor ([67.71.32.91]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040413181218.PLIZ15096.tomts25-srv.bellnexxia.net@alfajor>; Tue, 13 Apr 2004 14:12:18 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id EF1D8D72D7; Tue, 13 Apr 2004 14:12:20 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21589 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21589 >>> switch-to-buffer means "I specifically want the buffer in THIS window." >>> It should get an error if it can't do that. To display the buffer >>> in another window would be failing to do the intended job. > Obviously we need to distinguish between "switch-to-buffer the command" > and "switch-to-buffer" the function. I don't care about the behavior > of the command, but of the function. > They are the same. We could make it do something different, > then specially restore the old behavior for interactive calls only. Yes. E.g. we could add an argument `noother which says: don't try to use another window if the current one can't be used. This arg would be set to non-nil in interactive calls. > But I think it would be a change for the worse to do this. Why exactly? > And the problem is made worse because there is currently no function that > does what we want in such case, i.e. "show buffer B, preferably in the > current window". > Perhaps the right thing is to define a new function which does that. > It could be called select-buffer, or switch-to-buffer-somewhere. > It could leave you with that buffer visible in the selected window, > which would be the previously current buffer if that is possible. Problem is: many packages (bundled or not with Emacs) use switch-to-buffer as if it were that new function (i.e. they don't take into account the fact that switch-to-buffer might fail). So I'd rather change the behavior of the switch-to-buffer function and restore it for interactive cases or create a new command (which we'd bind to C-x b). Note that for most people, if they call switch-to-buffer instead of the new command, they won't notice the difference because they never have any dedicated window and they never use the command when the minibuffer is the currently selected window. Stefan