From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: why pop-to-buffer has this ugly behavior? Date: Thu, 22 Jan 2004 19:04:48 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074799076 13482 80.91.224.253 (22 Jan 2004 19:17:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 19:17:56 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 22 20:17:53 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AjkKu-0004TO-00 for ; Thu, 22 Jan 2004 20:17:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjkK5-0005Wg-QN for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Jan 2004 14:17:01 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-NNTP-Posting-Host: 132.204.24.84 Original-X-Complaints-To: abuse@umontreal.ca Original-X-Trace: charlie.risq.qc.ca 1074798288 132.204.24.84 (Thu, 22 Jan 2004 14:04:48 EST) Original-NNTP-Posting-Date: Thu, 22 Jan 2004 14:04:48 EST Original-Xref: shelby.stanford.edu gnu.emacs.help:120333 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:16277 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16277 > It is not the job of pop-to-buffer to decide on the buffer-name when to split > but it is the job of libraries like cus-edit.el to decide this. Separation of concern implies that cus-edit should not need to care and should not decide whether to split a window or create a new frame. It should be decided by the user's preference. Now, the bhavior of pop-to-buffer is sufficiently complex and customizable that I can't tell you why you see this difference, but it does not only depend on the buffer name but also on the current window (whether it's a minibuffer or a dedicated window, for example). > BTW: here is how XEmacs implements custom-create-buffer - IMO the right way: This way [i.e. using switch-to-buffer] breaks when called from the minibuffer, breaks when called from a dedicated window, and might not correspond to the user's preference. If all code used pop-to-buffer, ECB could solve all its problems by only customizing pop-to-buffer, so it obviously does not inherently make things hard for ECB-like libraries, quite the opposite. Stefan