From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Klaus Berndl Newsgroups: gmane.emacs.help Subject: Re: why pop-to-buffer has this ugly behavior? Date: 22 Jan 2004 19:43:49 +0100 Organization: "sd&m AG, Muenchen, Germany" 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 1074797354 9117 80.91.224.253 (22 Jan 2004 18:49:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 18:49:14 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 22 19:49:07 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 1Ajjt4-000205-00 for ; Thu, 22 Jan 2004 19:49:07 +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 1Ajjqs-0001Ng-MG for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Jan 2004 13:46:50 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fi.sn.net!newsfeed2.fi.sn.net!newsfeed.kabelfoon.nl!195.129.110.21.MISMATCH!bnewsfeed00.bru.ops.eu.uu.net!bnewsinpeer00.bru.ops.eu.uu.net!emea.uu.net!news.sdm.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 81 Original-NNTP-Posting-Host: sachrang.muc.sdm.de Original-X-Trace: news.sdm.de 1074797029 7289 193.102.181.40 (22 Jan 2004 18:43:49 GMT) Original-X-Complaints-To: usenet@news.sdm.de Original-NNTP-Posting-Date: Thu, 22 Jan 2004 18:43:49 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-Xref: shelby.stanford.edu gnu.emacs.help:120331 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:16274 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16274 Oops, please excuse making such noise..... next time i should switch on my brain before complaining ;-) Just examined the value of same-window-regexps........... which contains a regexp for these *Customize...* buffers... Please ignore my previous posting and please excuse! Klaus On 22 Jan 2004, Klaus Berndl wrote: > > This is the implementation of custom-create-buffer in GNU Emacs 21.3: > > ,---- > | (defun custom-buffer-create (options &optional name description) > | "Create a buffer containing OPTIONS. > | Optional NAME is the name of the buffer. > | OPTIONS should be an alist of the form ((SYMBOL WIDGET)...), where > | SYMBOL is a customization option, and WIDGET is a widget for editing > | that option." > | (unless name (setq name "*Customization*")) > | (kill-buffer (get-buffer-create name)) > | (pop-to-buffer (get-buffer-create name)) > | (custom-buffer-create-internal options description)) > `---- > > I have wondered why here pop-to-buffer does not split the unsplitted window > in my frame. Then i have tested the following (The value of > `pop-up-windows' is t!): > > (pop-to-buffer (get-buffer-create "*BlaBlaBla*")) > > which splits an unsplitted window in 2 windows - well! > > (pop-to-buffer (get-buffer-create "*Customization*")) > > which does not split an unsplitted windows in 2 - very bad and ugly! > > Conclusion: pop-up-buffer must have somewhere in the c-code - or maybe > display-buffer) but anyway - some logic which decides dependent on the > buffer-name if the window should be splitted or not?! I write this not to > the bug-list because it is not really a bug but it is a strong violation of > one of the most important design-principles: "Separation of concerns". > > 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. > > Ugly things like that makes it sometimes really hard to develop > elisp-libraries like ECB. > > Ciao, > Klaus > > P.S. > > BTW: here is how XEmacs implements custom-create-buffer - IMO the right > way: > > (defun custom-buffer-create (options &optional name description) > "Create a buffer containing OPTIONS. > Optional NAME is the name of the buffer. > OPTIONS should be an alist of the form ((SYMBOL WIDGET)...), where > SYMBOL is a customization option, and WIDGET is a widget for editing > that option." > (unless name (setq name "*Customization*")) > (kill-buffer (get-buffer-create name)) > (switch-to-buffer (get-buffer-create name)) > (custom-buffer-create-internal options description)) -- Klaus Berndl mailto: klaus.berndl@sdm.de sd&m AG http://www.sdm.de software design & management Carl-Wery-Str. 42, 81739 Muenchen, Germany Tel +49 89 63812-392, Fax -220