why pop-to-buffer has this ugly behavior?

why pop-to-buffer has this ugly behavior?

[Klaus Berndl]

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

Re: why pop-to-buffer has this ugly behavior?

[Klaus Berndl]

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!

<Blush>
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

Re: why pop-to-buffer has this ugly behavior?

[Stefan Monnier]

> 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

Re: why pop-to-buffer has this ugly behavior?

[Klaus Berndl]

I have already sent a followup to my first posting where i apologize for my
noise - was my fault - have forgotten the existence of
`same-window-regexps'...

So again: Please excuse!
Klaus

On Thu, 22 Jan 2004, Stefan Monnier wrote:



> > 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

-- 
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

Re: why pop-to-buffer has this ugly behavior?

[Kevin Rodgers]

Klaus Berndl wrote:

> 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".

C-h v same-window-regexps


-- 
Kevin Rodgers