unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Klaus Berndl <klaus.berndl@sdm.de>
Subject: why pop-to-buffer has this ugly behavior?
Date: 22 Jan 2004 19:34:26 +0100	[thread overview]
Message-ID: <uhdynvnm5.fsf@sdm.de> (raw)


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

             reply	other threads:[~2004-01-22 18:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-22 18:34 Klaus Berndl [this message]
2004-01-22 18:43 ` why pop-to-buffer has this ugly behavior? Klaus Berndl
2004-01-22 19:04 ` Stefan Monnier
2004-01-22 19:13   ` Klaus Berndl
2004-01-22 19:35 ` Kevin Rodgers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=uhdynvnm5.fsf@sdm.de \
    --to=klaus.berndl@sdm.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).