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
next 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).