Re: split-window-preferred-function

Re: split-window-preferred-function

[grischka]

> >>>> I still think this is wrong: the choice should be based on
> >>>> split-window-preferred-aspect-ratio.
> >> 
> >>> I cannot imagine how that would work.  Especially what would prevent
> >>> splitting to create windows which are too narrow?
> >> 
> >> The height and width thresholds would, of course.
>
> > Ah, ok.  I've thought split-window-preferred-aspect-ratio would obsolete
> > those two.  So now I agree with you.
>
> No, of course it can't replace them.  Also I originally thought
> aspect-ratio wouldn't be needed, we could just use (/ height-threshold
> weight-threshold), but that wouldn't work: I much prefer tall windows,
> but would prefer to use a height threshold smaller than 80.

I don't think that tuning the split-window concept will bring you 
any further. Such function is simply too low-level than that it 
could do what you want, that is to create new layout on-the-fly. 

Now you throw some options "min/max/preferred/threshold/ratio" at 
the user, then if yet it doesn't work at least can be customized 
how it doesn't.

But humans are bad in calculating inter-dependencies of dozens of 
options, while understand dependencies of geometry and content 
immediately. Whereas code knows very well about flags and states, 
but has no idea how to calculate quality in layout.

So why don't you let the user define the layout and make the code 
fill in the options. Where LAYOUT means what (class of) content 
shall be shown in what place, and OPTIONS for instance can mean 
what do do with space where the content is currently not available.

Have a look at elscreen.  Or think about html div tags, they define 
layout that only applies if there is content. 

--- grischka

Re: split-window-preferred-function

[martin rudalics]

 > I don't think that tuning the split-window concept will bring you
 > any further. Such function is simply too low-level than that it
 > could do what you want, that is to create new layout on-the-fly.

Here we are mostly concerned with using `split-window' for displaying a
buffer currently not present on the frame.  In particular we are
concerned with picking the optimal window to split and the optimal way
to split it.  While this will get us a new layout I wouldn't call it
"creating" a new layout.

 > So why don't you let the user define the layout and make the code
 > fill in the options. Where LAYOUT means what (class of) content
 > shall be shown in what place, and OPTIONS for instance can mean
 > what do do with space where the content is currently not available.
 >
 > Have a look at elscreen.  Or think about html div tags, they define
 > layout that only applies if there is content.

IIUC elscreen is useful for switching between existing layouts.  Such
layouts are obtained by recursively splitting a root window horizontally
or vertically.  You can record such a layout in volatile memory by
calling `current-window-configuration' and you can re-create it from
there via `set-window-configuration'.  But you cannot (easily) define
and subsequently create such a layout manually.  Hence elscreen seems
hardly of any help in this context.  Please correct me if I'm wrong.

I can think of two options:

1. Make the underlying window structure accessible in Elisp - via
    parameters or functions like `window-parent' and `set-window-parent'.
    This would require careful design of things like `set-window-parent'
    to avoid introducing incoherent or faulty window layouts via Elisp.

2. Write a collection of functions that recursively tile a root window
    in some well-defined manner according to rules that humans can easily
    write, read and understand.  Maybe some of these layouts should be
    depicted in a graphical fashion, for example, in the toolbar (my
    Thunderbird permits me to choose among three basic tilings).

Re: split-window-preferred-function

[grischka]

From: "martin rudalics":

> IIUC elscreen is useful for switching between existing layouts.  Such
> layouts are obtained by recursively splitting a root window horizontally
> or vertically.  You can record such a layout in volatile memory by
> calling `current-window-configuration' and you can re-create it from
> there via `set-window-configuration'.  But you cannot (easily) define
> and subsequently create such a layout manually.  Hence elscreen seems
> hardly of any help in this context.  Please correct me if I'm wrong.

Actually elscreen has a separate "layout creation" mode (although it
is not as easy to use, and also IMO redundant, it could as well just 
live record user changes made in the "real" frame). 

But yes, you can save everything to disk, anytime.  Means it allows 
to get used to something, body-language wise. 

> I can think of two options:
> 
> 1. Make the underlying window structure accessible in Elisp - via
>     parameters or functions like `window-parent' and `set-window-parent'.
>     This would require careful design of things like `set-window-parent'
>     to avoid introducing incoherent or faulty window layouts via Elisp.
> 
> 2. Write a collection of functions that recursively tile a root window
>     in some well-defined manner according to rules that humans can easily
>     write, read and understand.  Maybe some of these layouts should be
>     depicted in a graphical fashion, for example, in the toolbar (my
>     Thunderbird permits me to choose among three basic tilings).

Option three: Allow zero-width and zero-height windows. 

For example:

+---+-----------+
|   |           |
|   |           |
|   |           |
|   |           |
|   |           |
|   |           | <--
|   |           |
|   |           |
+===+===========+

As you don't see there is a zero-height window at bottom, which 
when "on" spans up to the arrow, but is invisible by default.

Such there is actually no need for the code to *ever* create 
new windows automatically, because the "tree" is already either 
predefined and/or customized. Just the sizes aren't filled in always.

All windows would have some target class-properties, like "file", 
"help", "commandline", so if some buffer needs to be shown, the 
buffer/window-manager (which of I assume emacs has one) can apply 
some logic which buffer to show in what window.

For example:

(window
    :name "bottom-display"
    :content-classes '("*help*" "*output*" ...)
    ...
    :visible 'if-needed

Still the user is allowed to modify the tree anytime of course, 
by split-window or whatever.  Just not the code.  

--- grischka

Re: split-window-preferred-function

[martin rudalics]

 > Actually elscreen has a separate "layout creation" mode (although it
 > is not as easy to use, and also IMO redundant, it could as well just
 > live record user changes made in the "real" frame).
 >
 > But yes, you can save everything to disk, anytime.  Means it allows
 > to get used to something, body-language wise.

I don't know much about elscreen.  Can you tell me the name of the
package / function(s) implementing "layout creation"?

 > Option three: Allow zero-width and zero-height windows.

I thought about that already although I personally dislike hidden
windows.

 > Such there is actually no need for the code to *ever* create
 > new windows automatically, because the "tree" is already either
 > predefined and/or customized. Just the sizes aren't filled in always.

Currently there is no predefined tree.  We still would have to
recursively split the root window in some way.

 > All windows would have some target class-properties, like "file",
 > "help", "commandline", so if some buffer needs to be shown, the
 > buffer/window-manager (which of I assume emacs has one) can apply
 > some logic which buffer to show in what window.

The target class property already exists in some sense - certain buffers
can be always shown in the same windows.  The buffer/window manager is
`display-buffer' which sets up the appropriate window for a buffer.

 > (window
 >     :name "bottom-display"
 >     :content-classes '("*help*" "*output*" ...)
 >     ...
 >     :visible 'if-needed

Yes.  We should enumerate useful configurations where, for example, the
bottom-most window is shared by help and compiler output (just that I
sometimes want to display *help* and *info* in one and the same frame).
In any case, we have to design rules for making these configurations
appear on the display.

 > Still the user is allowed to modify the tree anytime of course,
 > by split-window or whatever.  Just not the code.

And by delete-window, I presume.  Anyway, restoring a configuration that
existed already is less difficult.

Re: split-window-preferred-function

[grischka]

>  > Actually elscreen has a separate "layout creation" mode (although it
>  > is not as easy to use, and also IMO redundant, it could as well just
>  > live record user changes made in the "real" frame).
>  >
>  > But yes, you can save everything to disk, anytime.  Means it allows
>  > to get used to something, body-language wise.
> 
> I don't know much about elscreen.  Can you tell me the name of the
> package / function(s) implementing "layout creation"?

Oops, yes. The name is ECB, not elscreen.

> > Option three: Allow zero-width and zero-height windows.
> 
> I thought about that already although I personally dislike hidden
> windows.

I don't know.  In GUI programs many things are mostly not active.

> Currently there is no predefined tree.  We still would have to
> recursively split the root window in some way.

Well, currently. But you could easily define one. The default 
window configuration that emacs needs to be operable is rather 
simple. Basically two 50% windows from which one is initially 
hidden ;)

--- grischka

Re: split-window-preferred-function

[Juri Linkov]

> 2. Write a collection of functions that recursively tile a root window
>    in some well-defined manner according to rules that humans can easily
>    write, read and understand.  Maybe some of these layouts should be
>    depicted in a graphical fashion, for example, in the toolbar (my
>    Thunderbird permits me to choose among three basic tilings).

This is very much like Gnus already implements customization of different
layouts for the window configuration in emacs/lisp/gnus/gnus-win.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

split-window-preferred-function

[martin rudalics]

`split-window-preferred-function' appears half-baked: In
`display-buffer' its calls are preceded by things like

	  && (window_height (window) >= split_height_threshold
	  ...
	  && (window_height (window)
	      >= (2 * window_min_size_2 (XWINDOW (window), 0))))

Set to some horizontal splitting function, splitting will be wrongly
rejected when the original window is not sufficiently high and wrongly
accepted when the window is not wide enough.  Hence it seems that we
need something like `split-width-threshold' and a way to detect how
`split-window-preferred-function' is going to split the window in order
to know which of our checks should be applied.

Re: split-window-preferred-function

[Juri Linkov]

> `split-window-preferred-function' appears half-baked: In
> `display-buffer' its calls are preceded by things like
>
> 	  && (window_height (window) >= split_height_threshold
> 	  ...
> 	  && (window_height (window)
> 	      >= (2 * window_min_size_2 (XWINDOW (window), 0))))
>
> Set to some horizontal splitting function, splitting will be wrongly
> rejected when the original window is not sufficiently high and wrongly
> accepted when the window is not wide enough.  Hence it seems that we
> need something like `split-width-threshold' and a way to detect how
> `split-window-preferred-function' is going to split the window in order
> to know which of our checks should be applied.

Maybe a function in `split-window-preferred-function' should take care
of all these conditions to decide how to split within a given
window configuration?

This means we could remove `split-window' from the default value of
`split-window-preferred-function', and then check in `display-buffer'
if `split-window-preferred-function' is non-nil, then call it without
checking any condition.  Otherwise, call `split-window', i.e. exactly
as it was implemented before introducing `split-window-preferred-function'.

The following patch implements this (note that checking for non-nil
Vsplit_window_preferred_function is not necessary in the else-branch
because when Vsplit_window_preferred_function is called unconditionally
it never reaches this else-branch with the second place where
Fsplit_window is called).

Index: src/window.c
===================================================================
RCS file: /sources/emacs/emacs/src/window.c,v
retrieving revision 1.604
diff -c -w -b -r1.604 window.c
*** src/window.c	19 Mar 2008 15:18:29 -0000	1.604
--- src/window.c	20 Mar 2008 22:01:17 -0000
***************
*** 3850,3855 ****
--- 3850,3858 ----
  
        /* If the largest window is tall enough, full-width, and either eligible
  	 for splitting or the only window, split it.  */
+       if (!NILP (Vsplit_window_preferred_function))
+ 	window = call1 (Vsplit_window_preferred_function, window);
+       else
  	if (!NILP (window)
  	    && ! FRAME_NO_SPLIT_P (XFRAME (XWINDOW (window)->frame))
  	    && WINDOW_FULL_WIDTH_P (XWINDOW (window))
***************
*** 3857,3863 ****
  		   || (NILP (XWINDOW (window)->parent)))
  	  && (window_height (window)
  	      >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	window = call1 (Vsplit_window_preferred_function, window);
        else
  	{
  	  Lisp_Object upper, other;
--- 3860,3866 ----
  		|| (NILP (XWINDOW (window)->parent)))
  	    && (window_height (window)
  		>= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	  window = Fsplit_window (window, Qnil, Qnil);
        else
  	{
  	  Lisp_Object upper, other;
***************
*** 3872,3878 ****
  		       || (NILP (XWINDOW (window)->parent)))
  		   && (window_height (window)
  		       >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	    window = call1 (Vsplit_window_preferred_function, window);
  	  else
  	    window = Fget_lru_window (frames, Qnil);
  	  /* If Fget_lru_window returned nil, try other approaches.  */
--- 3875,3881 ----
  		  || (NILP (XWINDOW (window)->parent)))
  	      && (window_height (window)
  		  >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	    window = Fsplit_window (window, Qnil, Qnil);
  	  else
  	    window = Fget_lru_window (frames, Qnil);
  	  /* If Fget_lru_window returned nil, try other approaches.  */
***************
*** 7598,7604 ****
  to split windows horizontally or vertically or some mix of the two.
  It is called with a window as single argument and should split it in two
  and return the new window.  */);
!   Vsplit_window_preferred_function = intern ("split-window");
  
    DEFVAR_INT ("window-min-height", &window_min_height,
  	      doc: /* *Delete any window less than this tall (including its mode line).
--- 7601,7607 ----
  to split windows horizontally or vertically or some mix of the two.
  It is called with a window as single argument and should split it in two
  and return the new window.  */);
!   Vsplit_window_preferred_function = Qnil;
  
    DEFVAR_INT ("window-min-height", &window_min_height,
  	      doc: /* *Delete any window less than this tall (including its mode line).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[Stefan Monnier]

> Maybe a function in `split-window-preferred-function' should take care
> of all these conditions to decide how to split within a given
> window configuration?

Also to decide *if* to split a window.

> This means we could remove `split-window' from the default value of
> `split-window-preferred-function', and then check in `display-buffer'
> if `split-window-preferred-function' is non-nil, then call it without
> checking any condition.  Otherwise, call `split-window', i.e. exactly
> as it was implemented before introducing `split-window-preferred-function'.

I think we need to allow the function to return nil and in this case
continue with the rest of the code.  I.e. it should be possible to
reproduce in Elisp what happens when split-window-preferred-function
is nil.  A good way to make sure that's true is to write the code in
Elisp in the first place.


        Stefan

Re: split-window-preferred-function

[Juri Linkov]

> I think we need to allow the function to return nil and in this case
> continue with the rest of the code.  I.e. it should be possible to
> reproduce in Elisp what happens when split-window-preferred-function
> is nil.  A good way to make sure that's true is to write the code in
> Elisp in the first place.

If I understand you correctly, this patch implements what you meant:

Index: src/window.c
===================================================================
RCS file: /sources/emacs/emacs/src/window.c,v
retrieving revision 1.604
diff -c -w -b -r1.604 window.c
*** src/window.c	19 Mar 2008 15:18:29 -0000	1.604
--- src/window.c	22 Mar 2008 01:07:04 -0000
***************
*** 3848,3853 ****
--- 3848,3859 ----
        else
  	window = Fget_largest_window (frames, Qt);
  
+       if (!NILP (Vsplit_window_preferred_function))
+ 	tem = call1 (Vsplit_window_preferred_function, window);
+ 
+       if (!NILP (tem))
+ 	window = tem;
+       else
  	/* If the largest window is tall enough, full-width, and either eligible
  	   for splitting or the only window, split it.  */
  	if (!NILP (window)
***************
*** 3857,3863 ****
  		   || (NILP (XWINDOW (window)->parent)))
  	  && (window_height (window)
  	      >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	window = call1 (Vsplit_window_preferred_function, window);
        else
  	{
  	  Lisp_Object upper, other;
--- 3863,3869 ----
  		|| (NILP (XWINDOW (window)->parent)))
  	    && (window_height (window)
  		>= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	  window = Fsplit_window (window, Qnil, Qnil);
        else
  	{
  	  Lisp_Object upper, other;
***************
*** 3872,3878 ****
  		       || (NILP (XWINDOW (window)->parent)))
  		   && (window_height (window)
  		       >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	    window = call1 (Vsplit_window_preferred_function, window);
  	  else
  	    window = Fget_lru_window (frames, Qnil);
  	  /* If Fget_lru_window returned nil, try other approaches.  */
--- 3878,3884 ----
  		  || (NILP (XWINDOW (window)->parent)))
  	      && (window_height (window)
  		  >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	    window = Fsplit_window (window, Qnil, Qnil);
  	  else
  	    window = Fget_lru_window (frames, Qnil);
  	  /* If Fget_lru_window returned nil, try other approaches.  */
***************
*** 7598,7604 ****
  to split windows horizontally or vertically or some mix of the two.
  It is called with a window as single argument and should split it in two
  and return the new window.  */);
!   Vsplit_window_preferred_function = intern ("split-window");
  
    DEFVAR_INT ("window-min-height", &window_min_height,
  	      doc: /* *Delete any window less than this tall (including its mode line).
--- 7604,7610 ----
  to split windows horizontally or vertically or some mix of the two.
  It is called with a window as single argument and should split it in two
  and return the new window.  */);
!   Vsplit_window_preferred_function = Qnil;
  
    DEFVAR_INT ("window-min-height", &window_min_height,
  	      doc: /* *Delete any window less than this tall (including its mode line).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[Stefan Monnier]

>> I think we need to allow the function to return nil and in this case
>> continue with the rest of the code.  I.e. it should be possible to
>> reproduce in Elisp what happens when split-window-preferred-function
>> is nil.  A good way to make sure that's true is to write the code in
>> Elisp in the first place.

> If I understand you correctly, this patch implements what you meant:

Part of it, the missing parts:
1 - update the docstring of split_window_preferred_function.
2 - provide a non-nil default for split_window_preferred_function
    by moving the current C code that checks the size and calls
    split-window to Elisp.


-- Stefan


> Index: src/window.c
> ===================================================================
> RCS file: /sources/emacs/emacs/src/window.c,v
> retrieving revision 1.604
> diff -c -w -b -r1.604 window.c
> *** src/window.c	19 Mar 2008 15:18:29 -0000	1.604
> --- src/window.c	22 Mar 2008 01:07:04 -0000
> ***************
> *** 3848,3853 ****
> --- 3848,3859 ----
>         else
>   	window = Fget_largest_window (frames, Qt);
  
> +       if (!NILP (Vsplit_window_preferred_function))
> + 	tem = call1 (Vsplit_window_preferred_function, window);
> + 
> +       if (!NILP (tem))
> + 	window = tem;
> +       else
>   	/* If the largest window is tall enough, full-width, and either eligible
>   	   for splitting or the only window, split it.  */
>   	if (!NILP (window)
> ***************
> *** 3857,3863 ****
>   		   || (NILP (XWINDOW (window)->parent)))
>   	  && (window_height (window)
>> = (2 * window_min_size_2 (XWINDOW (window), 0))))
> ! 	window = call1 (Vsplit_window_preferred_function, window);
>         else
>   	{
>   	  Lisp_Object upper, other;
> --- 3863,3869 ----
>   		|| (NILP (XWINDOW (window)->parent)))
>   	    && (window_height (window)
>> = (2 * window_min_size_2 (XWINDOW (window), 0))))
> ! 	  window = Fsplit_window (window, Qnil, Qnil);
>         else
>   	{
>   	  Lisp_Object upper, other;
> ***************
> *** 3872,3878 ****
>   		       || (NILP (XWINDOW (window)->parent)))
>   		   && (window_height (window)
>> = (2 * window_min_size_2 (XWINDOW (window), 0))))
> ! 	    window = call1 (Vsplit_window_preferred_function, window);
>   	  else
>   	    window = Fget_lru_window (frames, Qnil);
>   	  /* If Fget_lru_window returned nil, try other approaches.  */
> --- 3878,3884 ----
>   		  || (NILP (XWINDOW (window)->parent)))
>   	      && (window_height (window)
>> = (2 * window_min_size_2 (XWINDOW (window), 0))))
> ! 	    window = Fsplit_window (window, Qnil, Qnil);
>   	  else
>   	    window = Fget_lru_window (frames, Qnil);
>   	  /* If Fget_lru_window returned nil, try other approaches.  */
> ***************
> *** 7598,7604 ****
>   to split windows horizontally or vertically or some mix of the two.
>   It is called with a window as single argument and should split it in two
>   and return the new window.  */);
> !   Vsplit_window_preferred_function = intern ("split-window");
  
>     DEFVAR_INT ("window-min-height", &window_min_height,
>   	      doc: /* *Delete any window less than this tall (including its mode line).
> --- 7604,7610 ----
>   to split windows horizontally or vertically or some mix of the two.
>   It is called with a window as single argument and should split it in two
>   and return the new window.  */);
> !   Vsplit_window_preferred_function = Qnil;
  
>     DEFVAR_INT ("window-min-height", &window_min_height,
>   	      doc: /* *Delete any window less than this tall (including its mode line).

> -- 
> Juri Linkov
> http://www.jurta.org/emacs/

Re: split-window-preferred-function

[Juri Linkov]

> 2 - provide a non-nil default for split_window_preferred_function
>     by moving the current C code that checks the size and calls
>     split-window to Elisp.

I tried to follow the current C code as close as possible, and the
result is the function `split-window-preferred-horizontally' below.
It is intended to be set as an option of `split-window-preferred-function'.
Then the other option for it should be nil that will continue the
standard processing of vertical splitting.

There is a comment in cus-start.el that says:

                      ;; FIXME: Add `sensibly' which chooses between
                      ;; vertical or horizontal splits depending on the size
                      ;; and shape of the window.

So `split-window-preferred-sensibly' could be implemented later too
as a similar function.

(defcustom split-width-threshold 100
  "A window must be at least this wide to be eligible for splitting
by `display-buffer'.  The value is in line units.
If there is only one window, it is split regardless of this value."
  :type 'integer
  :group 'windows)

(defun split-window-preferred-horizontally (window)
  (interactive)
  (if (and window
           (not (frame-parameter (window-frame window) 'unsplittable))
           (window-full-width-p window)
           (>= (window-width window) split-width-threshold)
           (>= (window-width window) (* 2 window-min-width)))
      (split-window window nil 'horiz)
    (get-lru-window)))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[Juri Linkov]

>>> I think we need to allow the function to return nil and in this case
>>> continue with the rest of the code.  I.e. it should be possible to
>>> reproduce in Elisp what happens when split-window-preferred-function
>>> is nil.  A good way to make sure that's true is to write the code in
>>> Elisp in the first place.
>
>> If I understand you correctly, this patch implements what you meant:
>
> Part of it, the missing parts:
> 1 - update the docstring of split_window_preferred_function.
> 2 - provide a non-nil default for split_window_preferred_function
>     by moving the current C code that checks the size and calls
>     split-window to Elisp.

Please see a complete patch with docstring updates:

Index: src/window.c
===================================================================
RCS file: /sources/emacs/emacs/src/window.c,v
retrieving revision 1.604
diff -c -w -b -r1.604 window.c
*** src/window.c	19 Mar 2008 15:18:29 -0000	1.604
--- src/window.c	27 Mar 2008 23:36:06 -0000
***************
*** 3848,3853 ****
--- 3848,3859 ----
        else
  	window = Fget_largest_window (frames, Qt);
  
+       if (!NILP (Vsplit_window_preferred_function))
+ 	tem = call1 (Vsplit_window_preferred_function, window);
+ 
+       if (!NILP (tem))
+ 	window = tem;
+       else
  	/* If the largest window is tall enough, full-width, and either eligible
  	   for splitting or the only window, split it.  */
  	if (!NILP (window)
***************
*** 3857,3863 ****
  		   || (NILP (XWINDOW (window)->parent)))
  	  && (window_height (window)
  	      >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	window = call1 (Vsplit_window_preferred_function, window);
        else
  	{
  	  Lisp_Object upper, other;
--- 3863,3869 ----
  		|| (NILP (XWINDOW (window)->parent)))
  	    && (window_height (window)
  		>= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	  window = Fsplit_window (window, Qnil, Qnil);
        else
  	{
  	  Lisp_Object upper, other;
***************
*** 3872,3878 ****
  		       || (NILP (XWINDOW (window)->parent)))
  		   && (window_height (window)
  		       >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	    window = call1 (Vsplit_window_preferred_function, window);
  	  else
  	    window = Fget_lru_window (frames, Qnil);
  	  /* If Fget_lru_window returned nil, try other approaches.  */
--- 3878,3884 ----
  		  || (NILP (XWINDOW (window)->parent)))
  	      && (window_height (window)
  		  >= (2 * window_min_size_2 (XWINDOW (window), 0))))
! 	    window = Fsplit_window (window, Qnil, Qnil);
  	  else
  	    window = Fget_lru_window (frames, Qnil);
  	  /* If Fget_lru_window returned nil, try other approaches.  */
***************
*** 7596,7604 ****
  	       doc: /* Function to use to split a window.
  This is used by `display-buffer' to allow the user to choose whether
  to split windows horizontally or vertically or some mix of the two.
  It is called with a window as single argument and should split it in two
! and return the new window.  */);
!   Vsplit_window_preferred_function = intern ("split-window");
  
    DEFVAR_INT ("window-min-height", &window_min_height,
  	      doc: /* *Delete any window less than this tall (including its mode line).
--- 7602,7613 ----
  	       doc: /* Function to use to split a window.
  This is used by `display-buffer' to allow the user to choose whether
  to split windows horizontally or vertically or some mix of the two.
+ When this variable is nil, `display-buffer' splits windows vertically.
+ Otherwise, `display-buffer' calls this function to split a window.
  It is called with a window as single argument and should split it in two
! and return the new window, or return an appropriate existing window
! if splitting is not eligible.  */);
!   Vsplit_window_preferred_function = Qnil;
  
    DEFVAR_INT ("window-min-height", &window_min_height,
  	      doc: /* *Delete any window less than this tall (including its mode line).

Index: lisp/cus-start.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/cus-start.el,v
retrieving revision 1.118
diff -c -r1.118 cus-start.el
*** lisp/cus-start.el	8 Feb 2008 20:12:26 -0000	1.118
--- lisp/cus-start.el	27 Mar 2008 23:37:05 -0000
***************
*** 346,358 ****
  	     (split-height-threshold windows integer)
               (split-window-preferred-function
                windows
!               (choice (const :tag "vertically" split-window)
                        ;; FIXME: Add `sensibly' which chooses between
                        ;; vertical or horizontal splits depending on the size
                        ;; and shape of the window.
                        (const :tag "horizontally"
!                              (lambda (window)
!                                (split-window window nil 'horiz))))
  	      "23.1")
  	     (window-min-height windows integer)
  	     (window-min-width windows integer)
--- 346,357 ----
  	     (split-height-threshold windows integer)
               (split-window-preferred-function
                windows
!               (choice (const :tag "vertically" nil)
                        ;; FIXME: Add `sensibly' which chooses between
                        ;; vertical or horizontal splits depending on the size
                        ;; and shape of the window.
                        (const :tag "horizontally"
!                              split-window-preferred-horizontally))
  	      "23.1")
  	     (window-min-height windows integer)
  	     (window-min-width windows integer)

Index: lisp/window.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/window.el,v
retrieving revision 1.131
diff -c -r1.131 window.el
*** lisp/window.el	8 Jan 2008 20:44:44 -0000	1.131
--- lisp/window.el	27 Mar 2008 23:36:37 -0000
***************
*** 614,619 ****
--- 614,661 ----
  	 (setq size (+ (window-width) size)))
      (split-window-save-restore-data (split-window nil size t) old-w)))
  
+ (defun split-window-preferred-horizontally (window)
+   "Split WINDOW horizontally or select an appropriate existing window.
+ It is called by `display-buffer' to split windows horizontally
+ when the option `split-window-preferred-function' is set to \"horizontally\".
+ This function tries to match the implementation of vertical splitting
+ in `display-buffer' as close as possible but with the logic of
+ horizontal splitting.  It returns a new window or an appropriate
+ existing window if splitting is not eligible."
+   (interactive)
+   ;; If the largest window is wide enough, eligible for splitting,
+   ;; and the only window, split it horizontally.
+   (if (and window
+            (not (frame-parameter (window-frame window) 'unsplittable))
+            (one-window-p (window-frame window))
+            (>= (window-width window) (* 2 window-min-width)))
+       (split-window window nil t)
+     ;; Otherwise, if the LRU window is wide enough, eligible for
+     ;; splitting and selected or the only window, split it horizontally.
+     (setq window (get-lru-window nil t))
+     (if (and window
+              (not (frame-parameter (window-frame window) 'unsplittable))
+              (or (eq window (selected-window))
+                  (one-window-p (window-frame window)))
+              (>= (window-width window) (* 2 window-min-width)))
+         (split-window window nil t)
+       ;; Otherwise, if get-lru-window returns nil, try other approaches.
+       (setq window (get-lru-window nil nil))
+       ;; Try visible frames first.
+       (unless window
+         (setq window (get-buffer-window (current-buffer) 'visible)))
+       (unless window
+         (setq window (get-largest-window 'visible)))
+       ;; If that didn't work, try iconified frames.
+       (unless window
+         (setq window (get-buffer-window (current-buffer) 0)))
+       (unless window
+         (setq window (get-largest-window 0)))
+       ;; As a last resort, make a new frame.
+       (unless window
+         (setq window (frame-selected-window (funcall pop-up-frame-function))))
+       window)))
+ 
  \f
  (defun set-window-text-height (window height)
    "Sets the height in lines of the text display area of WINDOW to HEIGHT.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[martin rudalics]

Wouldn't it be nicer to use something like

(or (get-lru-window nil nil)
     ;; Try visible frames first.
     (get-buffer-window (current-buffer) 'visible)
     (get-largest-window 'visible)
     ;; If that didn't work, try iconified frames.
     (get-buffer-window (current-buffer) 0)
     (get-largest-window 0)
     ;; As a last resort, make a new frame.
     (frame-selected-window (funcall pop-up-frame-function)))

at the end of `split-window-preferred-horizontally'?

Re: split-window-preferred-function

[Juri Linkov]

> Wouldn't it be nicer to use something like
>
> (or (get-lru-window nil nil)
>     ;; Try visible frames first.
>     (get-buffer-window (current-buffer) 'visible)
>     (get-largest-window 'visible)
>     ;; If that didn't work, try iconified frames.
>     (get-buffer-window (current-buffer) 0)
>     (get-largest-window 0)
>     ;; As a last resort, make a new frame.
>     (frame-selected-window (funcall pop-up-frame-function)))
>
> at the end of `split-window-preferred-horizontally'?

Of course, I already noticed that this part is eligible for optimization
in one `or', but I decided to try writing a close equivalent of
C code in Lisp, so it would be easier to put both versions side-by-side
(in horizontally split windows ;-) and compare their logics.  And I wrote
about this fact in the docstring as:

  This function tries to match the implementation of vertical splitting
  in `display-buffer' as close as possible but with the logic of
  horizontal splitting.

Not a big deal, I think.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[martin rudalics]

 > Of course, I already noticed that this part is eligible for optimization
 > in one `or', but I decided to try writing a close equivalent of
 > C code in Lisp, so it would be easier to put both versions side-by-side
 > (in horizontally split windows ;-) and compare their logics.  And I wrote
 > about this fact in the docstring as:
 >
 >   This function tries to match the implementation of vertical splitting
 >   in `display-buffer' as close as possible but with the logic of
 >   horizontal splitting.
 >
 > Not a big deal, I think.

You already wrote one third of `display-buffer' in Elisp.  What do you
think about rewriting the rest too?

Re: split-window-preferred-function

[Juri Linkov]

> You already wrote one third of `display-buffer' in Elisp.  What do you
> think about rewriting the rest too?

Currently a complete rewrite of `display-buffer' is not possible because
not all C internals used in `display-buffer' are exposed to Lisp.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[martin rudalics]

 > Currently a complete rewrite of `display-buffer' is not possible because
 > not all C internals used in `display-buffer' are exposed to Lisp.

IIUC we'd have to

(1) Write `display-buffer-1' and `no-switch-window' in Elisp.

(2) Expose `frame_sample_visibility' and `last_nonminibuf_frame' to Lisp
     code.  Maybe also `record_buffer'.

(3) Rewrite the `even-window-heights' stuff using `window-edges'.
     Somehow an `even-window-widths' is needed here anyway ;-)

Nothing in (1) and (2) would have to get documented in Info.  Am I
missing something?

Re: split-window-preferred-function

[Stefan Monnier]

>> You already wrote one third of `display-buffer' in Elisp.  What do you
>> think about rewriting the rest too?

> Currently a complete rewrite of `display-buffer' is not possible because
> not all C internals used in `display-buffer' are exposed to Lisp.

It'd be good to be able to write display-buffer in Elisp.


        Stefan

Re: split-window-preferred-function

[Richard Stallman]

    Currently a complete rewrite of `display-buffer' is not possible because
    not all C internals used in `display-buffer' are exposed to Lisp.

This change could involve exposing whatever else is needed.

Re: split-window-preferred-function

[martin rudalics]

 > This change could involve exposing whatever else is needed.

I'm not yet sure how to handle the following two:

		  || (NILP (XWINDOW (window)->parent))

and

	  if (!NILP (XWINDOW (window)->prev))
	    other = upper = XWINDOW (window)->prev;
	  if (!NILP (XWINDOW (window)->next))
	    other = XWINDOW (window)->next, upper = window;
           ...

I initially planned to use `window-edges' to check whether two windows
are "arrayed" in some sense.  That's not quite accurate when window
edges match but the involved windows have different parents.  Hence
enlarge_window could affect other windows and the overall behavior of
`display-buffer' might change.

XEmacs handles this by exposing `window-parent', `window-next', ... to
Elisp.  This would, however, contradict the Emacs ideology that Elisp
code should never see a non-leaf window.  In particular, we would have
to rewrite things like `adjust-window-trailing-edge' which currently
chokes on non-leaf windows.

BTW, do we want a `split-width-threshold'?

Re: split-window-preferred-function

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

Hi Martin,

> BTW, do we want a `split-width-threshold'?

What would that do?

Judging from the name I think it would inhibit splitting if the
resulting window would be smaller than that threshold and reuse the
least recently used window instead.  I'd welcome such a feature (I
usually don't want windows that are smaller than 80 columns), but
wouldn't we need the same for height, too?

Additionally we might need something like `split-window-special-regexp'
for buffers that should not obey this threshold.  For example I can
imagine that a minimum width of 80 columns is not what users expect for
a buffer displaying a speedbar-like file tree.  But maybe that's not
needed if all modes that use such special buffers call `split-window'
with explicit `size' parameter.

Bye,
Tassilo

Re: split-window-preferred-function

[martin rudalics]

 > What would that do?

The same as `split-height-threshold' - horizontally spoken ;-)

 > Judging from the name I think it would inhibit splitting if the
 > resulting window would be smaller than that threshold and reuse the
 > least recently used window instead.  I'd welcome such a feature (I
 > usually don't want windows that are smaller than 80 columns), but
 > wouldn't we need the same for height, too?

We have that already but hardly anyone is aware of it.  Its default
value is 500 (lines, nota bene).  The purpose of these variables is
trivial: Windows less than that are not split by `display-buffer'.

 > Additionally we might need something like `split-window-special-regexp'
 > for buffers that should not obey this threshold.  For example I can
 > imagine that a minimum width of 80 columns is not what users expect for
 > a buffer displaying a speedbar-like file tree.  But maybe that's not
 > needed if all modes that use such special buffers call `split-window'
 > with explicit `size' parameter.

We'd probably have `display-buffer' obey buffer-local values.  All this
can be written easier as soon as `display-buffer' is available in Elisp.

Re: split-window-preferred-function

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> What would that do?
>
> The same as `split-height-threshold' - horizontally spoken ;-)

Oh, indeed. :)

>> Judging from the name I think it would inhibit splitting if the
>> resulting window would be smaller than that threshold and reuse the
>> least recently used window instead.  I'd welcome such a feature (I
>> usually don't want windows that are smaller than 80 columns), but
>> wouldn't we need the same for height, too?
>
> We have that already but hardly anyone is aware of it.  Its default
> value is 500 (lines, nota bene).  The purpose of these variables is
> trivial: Windows less than that are not split by `display-buffer'.

I tried setting it to 20, but cannot see a difference.  My frame is 221
columns x 61 lines tall.  I'm in *scratch* (the only window) and eval

  (display-buffer "diary")
  (display-buffer "*Help*")

step by step, first with the default threshold of 500.  Because I use
split-window-preferred-horizontally the diary buffer is shown in a new
window right of the window holding *scratch*.  Now I eval the second
`display-buffer' and the right window's buffer is replaced with the
*Help* buffer.

With `split-height-threshold' set to 20 I get the same behavior.
Reading the `display-buffer' docstring I think instead of replacing the
right window's buffer it should instead split the left window
vertically, cause that's much bigger (61 lines) than the threshold.

Bye,
Tassilo

Re: split-window-preferred-function

[martin rudalics]

 > Because I use
 > split-window-preferred-horizontally the diary buffer is shown in a new
 > window right of the window holding *scratch*.  Now I eval the second
 > `display-buffer' and the right window's buffer is replaced with the
 > *Help* buffer.
 >
 > With `split-height-threshold' set to 20 I get the same behavior.
 > Reading the `display-buffer' docstring I think instead of replacing the
 > right window's buffer it should instead split the left window
 > vertically, cause that's much bigger (61 lines) than the threshold.

You can't see it because you split your windows horizontally.  Try with
vertical splitting.  The earlier mentioned `split-width-threshold' would
handle your case.

Re: split-window-preferred-function

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> Because I use split-window-preferred-horizontally the diary buffer is
>> shown in a new window right of the window holding *scratch*.  Now I
>> eval the second `display-buffer' and the right window's buffer is
>> replaced with the *Help* buffer.
>>
>> With `split-height-threshold' set to 20 I get the same behavior.
>> Reading the `display-buffer' docstring I think instead of replacing
>> the right window's buffer it should instead split the left window
>> vertically, cause that's much bigger (61 lines) than the threshold.
>
> You can't see it because you split your windows horizontally.  Try
> with vertical splitting.

Yes.  My point is that it would be better if `display-buffer' would try
to do a non-preferred split before falling back to reusing windows.  We
could change `split-window-preferred-function' to be an alist of split
functions.  Each function gets called, and if it's not able to do an
appropriate split, it returns nil.  If none of the functions splits the
window, `display-buffer's job is to reuse an existing window.

Vanilla emacs would ship with `split-window-functions' set to

  '(split-window-preferred-vertically
    split-window-preferred-horizontally)

Then `split-window-preferred-vertically' has to obey
`split-height-threshold' and `split-window-preferred-horizontally' has
to obey `split-width-threshold'.

Bye,
Tassilo

Re: split-window-preferred-function

[David De La Harpe Golden]

Tassilo Horn wrote:
> martin rudalics <rudalics@gmx.at> writes:
> 
> Hi Martin,
> 
>> BTW, do we want a `split-width-threshold'?
> 
> What would that do?
> 
> Judging from the name I think it would inhibit splitting if the
> resulting window would be smaller than that threshold and reuse the
> least recently used window instead.  I'd welcome such a feature (I
> usually don't want windows that are smaller than 80 columns), but
> wouldn't we need the same for height, too?
>

FWIW, I've currently got the following split-window-preferred function
in my .emacs  I don't really know the details of the relevant emacs
internals, it just did roughly what I wanted, so I was happy.

(setq split-window-preferred-function
      (lambda (window)
        (let ((w (window-width window))
              (h (window-height window))
              (force-vert nil)
              (w/h-ratio 2.0)) ; should be customizable.
          ;; Paranoia
          (when (> 1 w) (setq w 1))
          (when (> 1 h) (setq h 1))
          (when (>= 160 w) (setq force-vert t))
          (if (and (not force-vert)
                   (< (float w/h-ratio) (/ (float w) (float h))))
              (split-window window nil 'horiz)
            (split-window window)))))

Re: split-window-preferred-function

[Stefan Monnier]

>> This change could involve exposing whatever else is needed.
> I'm not yet sure how to handle the following two:
> 		  || (NILP (XWINDOW (window)->parent))

Wouldn't that be something like one-window-p ?

> and

> 	  if (!NILP (XWINDOW (window)->prev))
> 	    other = upper = XWINDOW (window)->prev;
> 	  if (!NILP (XWINDOW (window)->next))
> 	    other = XWINDOW (window)->next, upper = window;
>           ...

This part of code needs a comment explaining what is the use of `upper'
(i.e. why is enlarge_window called on `upper' rather than on `window'
(or `other')).

> I initially planned to use `window-edges' to check whether two windows
> are "arrayed" in some sense.  That's not quite accurate when window
> edges match but the involved windows have different parents.  Hence
> enlarge_window could affect other windows and the overall behavior of
> `display-buffer' might change.

Indeed, it's a problem.  Maybe a good solution is to change the
behavior: if you can't tell which if (next-window) is "->next" or not
just by looking at window-edges, then the user probably can't either, so
the current behavior (which depends on such a distinction) is not
great anyway.  Better would be to take all windows in a sequence of
next-window/previous-window which (according to window-edges) are
"siblings", and then rebalance them all.

> XEmacs handles this by exposing `window-parent', `window-next', ... to
> Elisp.  This would, however, contradict the Emacs ideology that Elisp
> code should never see a non-leaf window.  In particular, we would have
> to rewrite things like `adjust-window-trailing-edge' which currently
> chokes on non-leaf windows.

Of course, we can also expose window-next without exposing
window-parent, so we still only expose non-leaf windows.


        Stefan

Re: split-window-preferred-function

[martin rudalics]

 >>I'm not yet sure how to handle the following two:
 >>		  || (NILP (XWINDOW (window)->parent))
 >
 >
 > Wouldn't that be something like one-window-p ?

Probably, I haven't looked into this yet.

 >>	  if (!NILP (XWINDOW (window)->prev))
 >>	    other = upper = XWINDOW (window)->prev;
 >>	  if (!NILP (XWINDOW (window)->next))
 >>	    other = XWINDOW (window)->next, upper = window;
 >>          ...
 >
 >
 > This part of code needs a comment explaining what is the use of `upper'
 > (i.e. why is enlarge_window called on `upper' rather than on `window'
 > (or `other')).

Yes but I don't understand the rationale of this code.  Maybe I find
something in the ChangeLogs.  In any case, for horizontal splitting,
we'd have to do this for the left or right window too.  I could call
`window-tree' and look if the windows have some common prefix in that
tree, but that appears very contrived, IMHO.

 >>I initially planned to use `window-edges' to check whether two windows
 >>are "arrayed" in some sense.  That's not quite accurate when window
 >>edges match but the involved windows have different parents.  Hence
 >>enlarge_window could affect other windows and the overall behavior of
 >>`display-buffer' might change.
 >
 >
 > Indeed, it's a problem.  Maybe a good solution is to change the
 > behavior: if you can't tell which if (next-window) is "->next" or not
 > just by looking at window-edges, then the user probably can't either, so
 > the current behavior (which depends on such a distinction) is not
 > great anyway.  Better would be to take all windows in a sequence of
 > next-window/previous-window which (according to window-edges) are
 > "siblings", and then rebalance them all.

IIUC `balance-windows-area' works on all windows only.

 >>XEmacs handles this by exposing `window-parent', `window-next', ... to
 >>Elisp.  This would, however, contradict the Emacs ideology that Elisp
 >>code should never see a non-leaf window.  In particular, we would have
 >>to rewrite things like `adjust-window-trailing-edge' which currently
 >>chokes on non-leaf windows.
 >
 >
 > Of course, we can also expose window-next without exposing
 > window-parent, so we still only expose non-leaf windows.

I'm afraid not - `window-next' can name a non-leaf window.

Re: split-window-preferred-function

[Juri Linkov]

> I'm not yet sure how to handle the following two:
>
> 		  || (NILP (XWINDOW (window)->parent))

As you can see, I already implemented this in
`split-window-preferred-horizontally' as a call
to `one-window-p'.

> BTW, do we want a `split-width-threshold'?

In my initial patch I presented the variable `split-width-threshold',
but in the final installed patch I dropped this variable,
because I realized that it is not necessary.

The reason is simple: there is no sense to have more than two
automatically horizontally split side-by-side windows.  For instance,
I use the smallest readable font and on a wide screen I get 200 columns.
Splitting them in three parts gives less than 80-column wide windows that
is not comfortable width to work in most buffers.

It is true that some specialized features like speedbar might
require a narrow window, but they can create such a window
configuration explicitly.  So really automatic splitting in
more than 3 horizontally split windows is not necessary.

However, what is very much necessary, and what is still missing in
`split-window-preferred-horizontally' is the ability to
split _vertically_ in horizontally split windows.

Let's take for example `calendar'.  When we have two horizontally split
windows and call `M-x calendar', it displays the calendar window
in the adjacent window.  This is very inconvenient because the
calendar window is usually not higher than 8 lines and the
rest of its window below is filled by empty space:

    +------------+------------+
    |            |            |
    |            |  calendar  |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    +------------+------------+

It would be more preferable for `calendar' to split the current window
vertically and adjust its height like it already does:

    +------------+------------+
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    |            |            |
    +------------+            |
    |            |            |
    |  calendar  |            |
    |            |            |
    +------------+------------+

I'm not sure yet whether this behavior can be generalized in
`split-window-preferred-horizontally' or `calendar' should
treat it specially.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[martin rudalics]

 > It is true that some specialized features like speedbar might
 > require a narrow window, but they can create such a window
 > configuration explicitly.  So really automatic splitting in
 > more than 3 horizontally split windows is not necessary.

In the first configuration below (for example, displaying a speedbar in
window 1) people might want to split window 2 horizontally

+---+-----------------------------------+
| 1 | 2                                 |
|   |                                   |
|   |                                   |
|   |                                   |
|   |                                   |
|   |                                   |
+---+-----------------------------------+

while in the next configuration horizontal splitting appears less
desirable:

+------------------+--------------------+
| 3                | 4                  |
|                  |                    |
|                  |                    |
|                  |                    |
|                  |                    |
|                  |                    |
+------------------+--------------------+

How would I express that without `split-width-threshold'?

 > It would be more preferable for `calendar' to split the current window
 > vertically and adjust its height like it already does:
 >
 >     +------------+------------+
 >     |            |            |
 >     |            |            |
 >     |            |            |
 >     |            |            |
 >     |            |            |
 >     |            |            |
 >     |            |            |
 >     |            |            |
 >     +------------+            |
 >     |            |            |
 >     |  calendar  |            |
 >     |            |            |
 >     +------------+------------+
 >
 > I'm not sure yet whether this behavior can be generalized in
 > `split-window-preferred-horizontally' or `calendar' should
 > treat it specially.

Currently `display-buffer' would not split the left window vertically
because it is not full-width.  With `split-width-threshold'

	  && (WINDOW_FULL_WIDTH_P (XWINDOW (window)))

we could write something like

           (>= (window-width window) (/ split-width-threshold 2))

hence `split-width-threshold' would serve the dual role to allow
splitting a window horizontally when it's at least that wide and
vertically when it's at least half that wide (due to a preceding
horizontal split maybe).

Re: split-window-preferred-function

[Juri Linkov]

> Currently `display-buffer' would not split the left window vertically
> because it is not full-width.  With `split-width-threshold'
>
> 	  && (WINDOW_FULL_WIDTH_P (XWINDOW (window)))
>
> we could write something like
>
>           (>= (window-width window) (/ split-width-threshold 2))
>
> hence `split-width-threshold' would serve the dual role to allow
> splitting a window horizontally when it's at least that wide and
> vertically when it's at least half that wide (due to a preceding
> horizontal split maybe).

Yes, `split-width-threshold' might help in these situations.
But I think its default value should not be such large value as
`split-height-threshold' has.  However, for the default behavior of
vertical splitting this large default value seems right.

This means there is a difference in semantics of `split-height-threshold'
and `split-width-threshold'.  IOW, they are NOT complete equivalents
rotated 90 degrees.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[martin rudalics]

 > But I think its default value should not be such large value as
 > `split-height-threshold' has.

The current default value of `split-height-threshold' simply means that
no one ever know about or uses it.

 > However, for the default behavior of
 > vertical splitting this large default value seems right.
 >
 > This means there is a difference in semantics of `split-height-threshold'
 > and `split-width-threshold'.  IOW, they are NOT complete equivalents
 > rotated 90 degrees.

IMHO the difference is that the `split-width-threshold' default value
should be something like 80.  The `split-height-threshold' value would
have to be around 40 to be useful occasionally.

Re: split-window-preferred-function

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>> BTW, do we want a `split-width-threshold'?
>
> In my initial patch I presented the variable `split-width-threshold',
> but in the final installed patch I dropped this variable, because I
> realized that it is not necessary.
>
> The reason is simple: there is no sense to have more than two
> automatically horizontally split side-by-side windows.  For instance,
> I use the smallest readable font and on a wide screen I get 200
> columns.

I get 221 columns on my 24" (1900 dots wide) display.  There already are
30" displays out there that are 2500 dots wide.  Three side-by-side
windows are ok with them.  So IMO your assumption is not valid.

> Splitting them in three parts gives less than 80-column wide windows
> that is not comfortable width to work in most buffers.

Generally I'd agree that windows with less than 80 columns are not
comfortable, but that's a thing a user should decide.

> However, what is very much necessary, and what is still missing in
> `split-window-preferred-horizontally' is the ability to split
> _vertically_ in horizontally split windows.

Indeed, vertical splitting if horizontal splitting won't work (and the
other way round) would be a good feature.  But I had a different
implementation in mind.  How about my idea I described in
<871w5oo2qa.fsf@member.fsf.org>?

Bye,
Tassilo

Re: split-window-preferred-function

[Juri Linkov]

>> Splitting them in three parts gives less than 80-column wide windows
>> that is not comfortable width to work in most buffers.
>
> Generally I'd agree that windows with less than 80 columns are not
> comfortable, but that's a thing a user should decide.

It seems 80 columns is a good default for `split-width-threshold'.

>> However, what is very much necessary, and what is still missing in
>> `split-window-preferred-horizontally' is the ability to split
>> _vertically_ in horizontally split windows.
>
> Indeed, vertical splitting if horizontal splitting won't work (and the
> other way round) would be a good feature.  But I had a different
> implementation in mind.  How about my idea I described in
> <871w5oo2qa.fsf@member.fsf.org>?

I don't see how this would help to decide whether to split a window
vertically or horizontally, or to display a buffer in a new window.
For example:

+----------------+--------------------------------+
|                |                                |
|   80 columns   |        160 columns             |
|                |                                |
|                |                                |
|                |                                |
|                |                                |
+----------------+--------------------------------+

When the right window is wide enough to be split horizontally,
and point is in the left window, what is the best to do here?

1. display a buffer in the right window without splitting it;
2. split the wide right window horizontally and display a buffer
   in a new window;
3. split the left window vertically (this option is preferable
   for some buffers, e.g. for calendar)

And how to express these preferences using user options?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: split-window-preferred-function

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

> I don't see how this would help to decide whether to split a window
> vertically or horizontally, or to display a buffer in a new window.

The order of the splitting functions in the hypothetical
`split-window-functions' list would express the preference.  Each
function checks if it's applicable (wrt to
split-{width,height}-threshold) and returns nil, if it's not.

> For example:
>
> +----------------+--------------------------------+
> |                |                                |
> |   80 columns   |        160 columns             |
> |                |                                |
> |                |                                |
> |                |                                |
> |                |                                |
> +----------------+--------------------------------+
>
> When the right window is wide enough to be split horizontally, and
> point is in the left window, what is the best to do here?
>
> 1. display a buffer in the right window without splitting it;
> 2. split the wide right window horizontally and display a buffer
>    in a new window;
> 3. split the left window vertically (this option is preferable
>    for some buffers, e.g. for calendar)

By default I'd say the splitting functions only check if the current
window is wide/high enough.  So I the case above if horizontal splitting
is preferred and split-width-threshold is more than 40, the horizontal
splitting function would not be applicable and return nil.  The vertical
splitting function is the next and checks if the left window is higher
than split-height-threshold (the default should be changed to something
like 40).  If it is, then option 3 would be done.  If not, then it would
return nil, too.  In that case display-buffer would reuse the LRU window
which is the right one.

I think that's a sensible default.  Users are free to add other
functions.  For example the splitting functions could be extended to
search through all windows of the current frame to find one that's large
enough for a horizontal/vertical split.

Bye,
Tassilo

Re: split-window-preferred-function

[martin rudalics]

 >>+----------------+--------------------------------+
 >>|                |                                |
 >>|   80 columns   |        160 columns             |
 >>|                |                                |
 >>|                |                                |
 >>|                |                                |
 >>|                |                                |
 >>+----------------+--------------------------------+
 >>
 >>When the right window is wide enough to be split horizontally, and
 >>point is in the left window, what is the best to do here?
 >>
 >>1. display a buffer in the right window without splitting it;
 >>2. split the wide right window horizontally and display a buffer
 >>   in a new window;
 >>3. split the left window vertically (this option is preferable
 >>   for some buffers, e.g. for calendar)
 >
 >
 > By default I'd say the splitting functions only check if the current
 > window is wide/high enough.  So I the case above if horizontal splitting
 > is preferred and split-width-threshold is more than 40, the horizontal
 > splitting function would not be applicable and return nil.  The vertical
 > splitting function is the next and checks if the left window is higher
 > than split-height-threshold (the default should be changed to something
 > like 40).  If it is, then option 3 would be done.  If not, then it would
 > return nil, too.  In that case display-buffer would reuse the LRU window
 > which is the right one.
 >
 > I think that's a sensible default.  Users are free to add other
 > functions.  For example the splitting functions could be extended to
 > search through all windows of the current frame to find one that's large
 > enough for a horizontal/vertical split.

Sounds reasonable.  Currently, `display-buffer' searches for the largest
window and tries to split it regardless of which window is selected.  It
usually doesn't because the default value of `split-height-threshold'
prevents splitting.

Re: split-window-preferred-function

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>>>+----------------+--------------------------------+
>>>|                |                                |
>>>|   80 columns   |        160 columns             |
>>>|                |                                |
>>>|                |                                |
>>>|                |                                |
>>>|                |                                |
>>>+----------------+--------------------------------+
>>>
>>>When the right window is wide enough to be split horizontally, and
>>>point is in the left window, what is the best to do here?
>>>
>>>1. display a buffer in the right window without splitting it;
>>>2. split the wide right window horizontally and display a buffer
>>>   in a new window;
>>>3. split the left window vertically (this option is preferable
>>>   for some buffers, e.g. for calendar)
>>
>>
>> By default I'd say the splitting functions only check if the current
>> window is wide/high enough.  So I the case above if horizontal splitting
>> is preferred and split-width-threshold is more than 40, the horizontal
>> splitting function would not be applicable and return nil.  The vertical
>> splitting function is the next and checks if the left window is higher
>> than split-height-threshold (the default should be changed to something
>> like 40).  If it is, then option 3 would be done.  If not, then it would
>> return nil, too.  In that case display-buffer would reuse the LRU window
>> which is the right one.
>>
>> I think that's a sensible default.  Users are free to add other
>> functions.  For example the splitting functions could be extended to
>> search through all windows of the current frame to find one that's large
>> enough for a horizontal/vertical split.
>
> Sounds reasonable.  Currently, `display-buffer' searches for the
> largest window and tries to split it regardless of which window is
> selected.  It usually doesn't because the default value of
> `split-height-threshold' prevents splitting.

Ah, ok.  Then using the largest window for splitting should stay the
default, with sensible default values for
split-{width,height}-threshold, e.g. 80 and 40.

Bye,
Tassilo

Re: split-window-preferred-function

[Stefan Monnier]

>> I don't see how this would help to decide whether to split a window
>> vertically or horizontally, or to display a buffer in a new window.

> The order of the splitting functions in the hypothetical
> `split-window-functions' list would express the preference.  Each
> function checks if it's applicable (wrt to
> split-{width,height}-threshold) and returns nil, if it's not.

I still think this is wrong: the choice should be based on
split-window-preferred-aspect-ratio.


        Stefan

Re: split-window-preferred-function

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I don't see how this would help to decide whether to split a window
>>> vertically or horizontally, or to display a buffer in a new window.
>
>> The order of the splitting functions in the hypothetical
>> `split-window-functions' list would express the preference.  Each
>> function checks if it's applicable (wrt to
>> split-{width,height}-threshold) and returns nil, if it's not.
>
> I still think this is wrong: the choice should be based on
> split-window-preferred-aspect-ratio.

I cannot imagine how that would work.  Especially what would prevent
splitting to create windows which are too narrow?

Bye,
Tassilo

Re: split-window-preferred-function

[Stefan Monnier]

>>>> I don't see how this would help to decide whether to split a window
>>>> vertically or horizontally, or to display a buffer in a new window.
>> 
>>> The order of the splitting functions in the hypothetical
>>> `split-window-functions' list would express the preference.  Each
>>> function checks if it's applicable (wrt to
>>> split-{width,height}-threshold) and returns nil, if it's not.
>> 
>> I still think this is wrong: the choice should be based on
>> split-window-preferred-aspect-ratio.

> I cannot imagine how that would work.  Especially what would prevent
> splitting to create windows which are too narrow?

The height and width thresholds would, of course.


        Stefan

Re: split-window-preferred-function

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I still think this is wrong: the choice should be based on
>>> split-window-preferred-aspect-ratio.
>
>> I cannot imagine how that would work.  Especially what would prevent
>> splitting to create windows which are too narrow?
>
> The height and width thresholds would, of course.

Ah, ok.  I've thought split-window-preferred-aspect-ratio would obsolete
those two.  So now I agree with you.

Bye,
Tassilo

Re: split-window-preferred-function

[Stefan Monnier]

>>>> I still think this is wrong: the choice should be based on
>>>> split-window-preferred-aspect-ratio.
>> 
>>> I cannot imagine how that would work.  Especially what would prevent
>>> splitting to create windows which are too narrow?
>> 
>> The height and width thresholds would, of course.

> Ah, ok.  I've thought split-window-preferred-aspect-ratio would obsolete
> those two.  So now I agree with you.

No, of course it can't replace them.  Also I originally thought
aspect-ratio wouldn't be needed, we could just use (/ height-threshold
weight-threshold), but that wouldn't work: I much prefer tall windows,
but would prefer to use a height threshold smaller than 80.


        Stefan

Re: split-window-preferred-function

[martin rudalics]

 > Maybe a function in `split-window-preferred-function' should take care
 > of all these conditions to decide how to split within a given
 > window configuration?

Writing such a function is not entirely trivial.  Who's supposed to
write `split-window-preferred-function' in the first place?  Wasn't the
original motivation of this to simply allow horizontal splitting?

 > The following patch implements this (note that checking for non-nil
 > Vsplit_window_preferred_function is not necessary in the else-branch
 > because when Vsplit_window_preferred_function is called unconditionally
 > it never reaches this else-branch with the second place where
 > Fsplit_window is called).

Looks good.  But as Stefan remarked the function should return nil and
have `disply-buffer' continue the standard processing of this when it
was not able to split the window for whatever reason.

Re: split-window-preferred-function

[Juri Linkov]

>> Maybe a function in `split-window-preferred-function' should take care
>> of all these conditions to decide how to split within a given
>> window configuration?
>
> Writing such a function is not entirely trivial.  Who's supposed to
> write `split-window-preferred-function' in the first place?  Wasn't the
> original motivation of this to simply allow horizontal splitting?

Maybe we should write a horizontal splitting version of
split-window-preferred-function that will split horizontally
if the value of a new boolean user option is non-nil,
or return nil otherwise to continue the standard processing
of vertical splitting?

-- 
Juri Linkov
http://www.jurta.org/emacs/