`split-window-preferred-horizontally'

`split-window-preferred-horizontally'

[David Hansen]

Hello,

why was `split-window-preferred-horizontally' removed?  It did exactly
what I wanted.  How am i supposed to get the old behavior back? I had

(setq split-window-preferred-function
      #'(lambda (window)
          (when (>= (frame-width) 160)
              (split-window-preferred-horizontally window))))

In my ~/.emacs. Right now I'm trying

(setq split-window-preferred-function 'sensibly)

But it behaves pretty weird.  E.g  in a huge frame split once
horizontally `iswitchb-buffer-other-window' chooses the same window, as
does C-h k (IMHO these are bugs).

David

Re: `split-window-preferred-horizontally'

[martin rudalics]

 > why was `split-window-preferred-horizontally' removed?  It did exactly
 > what I wanted.  How am i supposed to get the old behavior back? I had
 >
 > (setq split-window-preferred-function
 >       #'(lambda (window)
 >           (when (>= (frame-width) 160)
 >               (split-window-preferred-horizontally window))))
 >
 > In my ~/.emacs. Right now I'm trying

I don't quite understand why you're using `frame-width' here.  It hardly
seems to DTRT when WINDOW is not full-width.  Can you try with

(setq split-window-preferred-function
       #'(lambda (window)
           (if (>= (window-width window) 60)
               (split-window window nil t)
	    (split-window window))))

 > Right now I'm trying
 >
 > (setq split-window-preferred-function 'sensibly)
 >
 > But it behaves pretty weird.  E.g  in a huge frame split once
 > horizontally `iswitchb-buffer-other-window' chooses the same window, as
 > does C-h k (IMHO these are bugs).

I'm afraid the default value of `split-width-threshold' is too large for
you.  Please try with a smaller value and tell me whether it still
behaves weirdly.  I yet have to find a solution how "sensibly" should
behave.  Can you suggest one?

Re: `split-window-preferred-horizontally'

[David Hansen]

On Sat, 07 Jun 2008 00:01:59 +0200 martin rudalics wrote:

> I'm afraid the default value of `split-width-threshold' is too large for
> you.  Please try with a smaller value and tell me whether it still
> behaves weirdly.  I yet have to find a solution how "sensibly" should
> behave.  Can you suggest one?

That's how I would like it:

If the *frame* is >= 160 chars wide

  - if it is already (horizontally) split use the *other* window with
    all the `*-other-window' commands and `display-buffer'

  - otherwise split it horizontally.

If the *frame* is < 160 chars wide do above with s/horizontally/vertically/
(as the default behavior already is).

I suspect that emacs thinks my already (horizontally) split frame is to
small because the *window* is just 80 + ε chars wide.

David

Re: `split-window-preferred-horizontally'

[Stefan Monnier]

>> why was `split-window-preferred-horizontally' removed?  It did exactly
>> what I wanted.  How am i supposed to get the old behavior back? I had
>> 
>> (setq split-window-preferred-function
>> #'(lambda (window)
>> (when (>= (frame-width) 160)
>> (split-window-preferred-horizontally window))))
>> 
>> In my ~/.emacs. Right now I'm trying

> I don't quite understand why you're using `frame-width' here.  It hardly
> seems to DTRT when WINDOW is not full-width.  Can you try with

> (setq split-window-preferred-function
>       #'(lambda (window)
>           (if (>= (window-width window) 60)
>               (split-window window nil t)
> 	    (split-window window))))

>> Right now I'm trying
>> 
>> (setq split-window-preferred-function 'sensibly)
>> 
>> But it behaves pretty weird.  E.g  in a huge frame split once
>> horizontally `iswitchb-buffer-other-window' chooses the same window, as
>> does C-h k (IMHO these are bugs).

> I'm afraid the default value of `split-width-threshold' is too large for
> you.  Please try with a smaller value and tell me whether it still
> behaves weirdly.  I yet have to find a solution how "sensibly" should
> behave.  Can you suggest one?

BTW, shouldn't `sensibly' be the default?
Or even the only acceptable setting (besides setting it to
a home-cooked function)?
I mean the nil value can be simulated with

   (setq split-width-threshold most-positive-fixnum)

and the `horizontal' value can be emulated with

   (setq split-height-threshold most-positive-fixnum)

If most-positive-fixnum is too inconvenient, we could accept a nil
setting for the thresholds to mean the same as most-positive-fixnum.


        Stefan

Re: `split-window-preferred-horizontally'

[Juanma Barranquero]

On Sat, Jun 7, 2008 at 03:44, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> BTW, shouldn't `sensibly' be the default?

And BTW, split-window-preferred-function's docstring is horribly
defcustom-oriented. `Vertically', `Horizontally' and `Sensibly' are
*not* the values the variable can have...

   Juanma

Re: `split-window-preferred-horizontally'

[martin rudalics]

 > That's how I would like it:
 >
 > If the *frame* is >= 160 chars wide
 >
 >   - if it is already (horizontally) split use the *other* window with
 >     all the `*-other-window' commands and `display-buffer'

`split-window-preferred-function' should decide if and how to split the
largest (or most recently used) window offered by `display-buffer'.  It
cannot decide which window to use when _no_ window gets split.

 >   - otherwise split it horizontally.
 >
 > If the *frame* is < 160 chars wide do above with s/horizontally/vertically/
 > (as the default behavior already is).

(defun my-spf (window)
   (if (>= (frame-width (window-frame window)) 120)
       (when (window-full-width-p window)
	(let ((split-width-threshold 120))
	  (split-window window nil t)))
     (split-window)))

seems to do what you want with a value of 120 - I can't test 160 here.

 > I suspect that emacs thinks my already (horizontally) split frame is to
 > small because the *window* is just 80 + ? chars wide.

The value of `split-width-threshold' must be set accordingly to handle
this when your frame contains more than one window.  If WINDOW is 120
columns wide, `split-width-threshold' equals 160, and you have more than
one window on your frame, `split-window' should refuse to split WINDOW.

Re: `split-window-preferred-horizontally'

[martin rudalics]

 > And BTW, split-window-preferred-function's docstring is horribly
 > defcustom-oriented. `Vertically', `Horizontally' and `Sensibly' are
 > *not* the values the variable can have...

But the doc-string is also what people customizing this read.  I once
used to put the valid values like `t' in the doc-string, and
`vertically' plus `t' in parentheses in the tags of the customization
interface and people complained.  Hence, I don't know how to do this
right.  Please write a better solution than the current one.

Re: `split-window-preferred-horizontally'

[martin rudalics]

 > BTW, shouldn't `sensibly' be the default?

As soon as we have decided on a reasonable standard behavior.

 > Or even the only acceptable setting (besides setting it to
 > a home-cooked function)?
 > I mean the nil value can be simulated with
 >
 >    (setq split-width-threshold most-positive-fixnum)
 >
 > and the `horizontal' value can be emulated with
 >
 >    (setq split-height-threshold most-positive-fixnum)
 >
 > If most-positive-fixnum is too inconvenient, we could accept a nil
 > setting for the thresholds to mean the same as most-positive-fixnum.

Sounds reasonable.  But how do we present the conventional `vertical'
default value in the customization interface?

Re: `split-window-preferred-horizontally'

[Juanma Barranquero]

On Sat, Jun 7, 2008 at 10:21, martin rudalics <rudalics@gmx.at> wrote:
>> And BTW, split-window-preferred-function's docstring is horribly
>> defcustom-oriented. `Vertically', `Horizontally' and `Sensibly' are
>> *not* the values the variable can have...
>
> But the doc-string is also what people customizing this read.

Yes. There are lot of variables that can be customized, and the
docstring usually reflects the values that it can have, not the tags
of the defcustom declaration. That's what the tags are for: to help
the people who's going through the customization interface.

>  I once
> used to put the valid values like `t' in the doc-string, and
> `vertically' plus `t' in parentheses in the tags of the customization
> interface and people complained. Hence, I don't know how to do this
> right.  Please write a better solution than the current one.

If I try to set up this variable out of customize (which I avoid like
hell), the current docstring is simply wrong. I had to go to the
source code to know what  *really* are the allowed values. The
docstring should reflect the truth (which, in this case, is that
`split-window-preferred-function' can have values `horizontally',
`sensibly', nil, or a function); then the defcustom tags would do its
job.

The following is what I would do (the specific wording is irrelevant).

--- window.el	6 Jun 2008 08:00:59 -0000	1.137
+++ window.el	7 Jun 2008 12:40:44 -0000
@@ -743,9 +743,12 @@
 (defcustom split-window-preferred-function nil
   "How `display-buffer' shall split windows.
-Choices are `Vertically', `Horizontally', and `Sensibly' where
-the latter attempts to split wide windows horizontally, narrow
-ones vertically.  Alternatively, you can set this to a function
-called with a window as single argument to split that window in
-two and return the new window."
+Choices are:
+  - `horizontally'   windows are split horizontally
+  - `sensibly'       attempt to split wide windows horizontally,
+                       narrow ones vertically
+  - nil              windows are split vertically
+  - a function       it will be called with a window as a single
+                       argument; it should split it in two and
+                       return the new window."
   :type '(choice
 	  (const :tag "Vertically" nil)

Re: `split-window-preferred-horizontally'

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

  > BTW, shouldn't `sensibly' be the default?
  > Or even the only acceptable setting (besides setting it to
  > a home-cooked function)?
  > I mean the nil value can be simulated with
  >
  >    (setq split-width-threshold most-positive-fixnum)
  >
  > and the `horizontal' value can be emulated with
  >
  >    (setq split-height-threshold most-positive-fixnum)
  >
  > If most-positive-fixnum is too inconvenient, we could accept a nil
  > setting for the thresholds to mean the same as most-positive-fixnum.

Is the attached patch what you mean?  There's yet no clever default for
handling the height/width aspect ratio.


[-- Attachment #2: window.el.patch --]
[-- Type: text/plain, Size: 8594 bytes --]

*** window.el.~1.137.~	Fri Jun  6 10:01:10 2008
--- window.el	Sat Jun  7 16:34:44 2008
***************
*** 741,771 ****
    :group 'windows)
  
  (defcustom split-window-preferred-function nil
!   "How `display-buffer' shall split windows.
! Choices are `Vertically', `Horizontally', and `Sensibly' where
! the latter attempts to split wide windows horizontally, narrow
! ones vertically.  Alternatively, you can set this to a function
! called with a window as single argument to split that window in
! two and return the new window."
!   :type '(choice
! 	  (const :tag "Vertically" nil)
! 	  (const :tag "Horizontally" horizontally)
! 	  (const :tag "Sensibly" sensibly)
! 	  (function :tag "Function"))
    :version "23.1"
    :group 'windows)
  
! (defcustom split-height-threshold 80
!   "Minimum height of window to be split vertically by `display-buffer'.
! If there is only one window, it can be split regardless of this."
    :type 'number
    :version "23.1"
    :group 'windows)
  
! (defcustom split-width-threshold 160
!   "Minimum width of window to be split horizontally by `display-buffer'.
! If there is only one window, it can be split regardless of this."
!   :type 'number
    :version "23.1"
    :group 'windows)
  
--- 741,775 ----
    :group 'windows)
  
  (defcustom split-window-preferred-function nil
!   "Function for `display-buffer' to split windows.
! If non-nil a function called with a window as single argument to
! split that window in two and return the new window.  If nil
! `display-buffer' will split the window according to the values of
! `split-height-threshold' and `split-width-threshold'."
!   :type '(choice (const nil) (function :tag "Function"))
    :version "23.1"
    :group 'windows)
  
! (defcustom split-height-threshold nil
!   "Minimum height of window to be split vertically.
! If the value is a number `display-buffer' can split a window only
! if it has at least as many lines.  If the value is nil
! `display-buffer' cannot split the window vertically.  If the
! window is the only window on its frame it can be split regardless
! of this value."
!   :type '(choice (const :tag "inhibit" nil)
! 		 (number :tag "lines"))
    :type 'number
    :version "23.1"
    :group 'windows)
  
! (defcustom split-width-threshold nil
!   "Minimum width of window to be split horizontally.
! If the value is a number `display-buffer' can split a window only
! if it has at least as many columns.  If the value is nil
! `display-buffer' cannot split the window horizontally."
!   :type '(choice (const :tag "inhibit" nil)
! 		 (number :tag "columns"))
    :version "23.1"
    :group 'windows)
  
***************
*** 780,787 ****
  - `window-size-fixed' is either nil or equals `width' for the buffer of
    WINDOW.
  
! - WINDOW is at least as high as `split-height-threshold' or it is
!   the only window on its frame.
  
  - When WINDOW is split evenly, the emanating windows are at least
    `window-min-height' lines tall and can accomodate at least one
--- 784,790 ----
  - `window-size-fixed' is either nil or equals `width' for the buffer of
    WINDOW.
  
! - WINDOW is at least as high as `split-height-threshold'.
  
  - When WINDOW is split evenly, the emanating windows are at least
    `window-min-height' lines tall and can accomodate at least one
***************
*** 805,861 ****
  	  ;; and at least twice as wide as `window-min-width' and 2 (the
  	  ;; latter value is hardcoded).
  	  (and (memq window-size-fixed '(nil height))
  	       (>= (window-width window)
  		   (max split-width-threshold
  			(* 2 (max window-min-width 2)))))
  	;; A window can be split vertically when its height is not
! 	;; fixed, it is at least `split-height-threshold' lines high or
! 	;; the only window on its frame, and it is at least twice as
! 	;; high as `window-min-height' and 2 if it has a modeline or 1.
  	(and (memq window-size-fixed '(nil width))
  	     (>= (window-height window)
! 		 (max (if (one-window-p 'nomini) 0 split-height-threshold)
  		      (* 2 (max window-min-height
  				(if mode-line-format 2 1))))))))))
  
  (defun window--try-to-split-window (window)
    "Split window WINDOW if it is splittable.
! See `split-window-preferred-function' for how WINDOW shall be
! split.  See `window--splittable-p' for how to determine whether a
! window is splittable.  If WINDOW can be split, return the value
! returned by `split-window' or `split-window-preferred-function'."
    (when (and (window-live-p window)
  	     ;; Testing `window-full-width-p' here hardly makes any
  	     ;; sense nowadays.  This can be done more intuitively by
  	     ;; setting up `split-width-threshold' appropriately.
  	     (not (frame-parameter (window-frame window) 'unsplittable)))
!     (or (and (not split-window-preferred-function)
! 	     (window--splittable-p window)
  	     (split-window window))
! 	(and (eq split-window-preferred-function 'horizontally)
! 	     (window--splittable-p window t)
  	     (split-window window nil t))
! 	(and (eq split-window-preferred-function 'sensibly)
! 	     ;; The following naive aspect-ratio test should become
! 	     ;; more sensible.
! 	     (or (and (> (window-width window) (window-height window))
! 		      (window--splittable-p window t)
! 		      (split-window window nil t))
! 		 (and (window--splittable-p window)
! 		      (split-window window))))
  	(and (functionp split-window-preferred-function)
  	     (funcall split-window-preferred-function window)))))
  
  (defun window--frame-usable-p (frame)
    "Return frame FRAME if it can be used to display another buffer."
!   (let ((window (frame-root-window frame)))
!     ;; `frame-root-window' may be an internal window which is considered
!     ;; "dead" by `window-live-p'.  Hence if `window' is not live we
!     ;; implicitly know that `frame' has a visible window we can use.
!     (when (or (not (window-live-p window))
! 	      (and (not (window-minibuffer-p window))
! 		   (not (window-dedicated-p window))))
!       frame)))
  
  (defcustom even-window-heights t
    "If non-nil `display-buffer' will try to even window heights.
--- 808,861 ----
  	  ;; and at least twice as wide as `window-min-width' and 2 (the
  	  ;; latter value is hardcoded).
  	  (and (memq window-size-fixed '(nil height))
+ 	       (numberp split-width-threshold)
  	       (>= (window-width window)
  		   (max split-width-threshold
  			(* 2 (max window-min-width 2)))))
  	;; A window can be split vertically when its height is not
! 	;; fixed, it is at least `split-height-threshold' lines high,
! 	;; and it is at least twice as high as `window-min-height' and 2
! 	;; if it has a modeline or 1.
  	(and (memq window-size-fixed '(nil width))
+ 	     (numberp split-height-threshold)
  	     (>= (window-height window)
! 		 (max split-height-threshold
  		      (* 2 (max window-min-height
  				(if mode-line-format 2 1))))))))))
  
  (defun window--try-to-split-window (window)
    "Split window WINDOW if it is splittable.
! See `window--splittable-p' for how to determine whether a window
! is splittable.  If WINDOW can be split, return the value returned
! by `split-window' or `split-window-preferred-function'."
    (when (and (window-live-p window)
  	     ;; Testing `window-full-width-p' here hardly makes any
  	     ;; sense nowadays.  This can be done more intuitively by
  	     ;; setting up `split-width-threshold' appropriately.
  	     (not (frame-parameter (window-frame window) 'unsplittable)))
!     (or (and (window--splittable-p window)
  	     (split-window window))
! 	(and (window--splittable-p window t)
  	     (split-window window nil t))
! 	(and (with-selected-window window
! 	       (one-window-p 'nomini))
! 	     (let ((split-height-threshold 0))
! 	       (window--splittable-p window)
! 	       (split-window window)))
  	(and (functionp split-window-preferred-function)
  	     (funcall split-window-preferred-function window)))))
  
  (defun window--frame-usable-p (frame)
    "Return frame FRAME if it can be used to display another buffer."
!   (when (framep frame)
!     (let ((window (frame-root-window frame)))
!       ;; `frame-root-window' may be an internal window which is considered
!       ;; "dead" by `window-live-p'.  Hence if `window' is not live we
!       ;; implicitly know that `frame' has a visible window we can use.
!       (when (or (not (window-live-p window))
! 		(and (not (window-minibuffer-p window))
! 		     (not (window-dedicated-p window))))
! 	frame))))
  
  (defcustom even-window-heights t
    "If non-nil `display-buffer' will try to even window heights.

Re: `split-window-preferred-horizontally'

[martin rudalics]

> The following is what I would do (the specific wording is irrelevant).
> 
> --- window.el	6 Jun 2008 08:00:59 -0000	1.137
> +++ window.el	7 Jun 2008 12:40:44 -0000
> @@ -743,9 +743,12 @@
>  (defcustom split-window-preferred-function nil
>    "How `display-buffer' shall split windows.
> -Choices are `Vertically', `Horizontally', and `Sensibly' where
> -the latter attempts to split wide windows horizontally, narrow
> -ones vertically.  Alternatively, you can set this to a function
> -called with a window as single argument to split that window in
> -two and return the new window."
> +Choices are:
> +  - `horizontally'   windows are split horizontally
> +  - `sensibly'       attempt to split wide windows horizontally,
> +                       narrow ones vertically
> +  - nil              windows are split vertically
> +  - a function       it will be called with a window as a single
> +                       argument; it should split it in two and
> +                       return the new window."
>    :type '(choice
>  	  (const :tag "Vertically" nil)

Yes that makes sense.  Let's see what Stefan says how to resolve this.

Re: `split-window-preferred-horizontally'

[Stefan Monnier]

>> BTW, shouldn't `sensibly' be the default?
> As soon as we have decided on a reasonable standard behavior.

>> Or even the only acceptable setting (besides setting it to
>> a home-cooked function)?
>> I mean the nil value can be simulated with
>> 
>> (setq split-width-threshold most-positive-fixnum)
>> 
>> and the `horizontal' value can be emulated with
>> 
>> (setq split-height-threshold most-positive-fixnum)
>> 
>> If most-positive-fixnum is too inconvenient, we could accept a nil
>> setting for the thresholds to mean the same as most-positive-fixnum.

> Sounds reasonable.  But how do we present the conventional `vertical'
> default value in the customization interface?

I do not understand the question.  `vertical' is nil, so it's (setq
split-width-threshold most-positive-fixnum).  Right?


        Stefan

Re: `split-window-preferred-horizontally'

[Stefan Monnier]

> Is the attached patch what you mean?

That looks right, yes.  Tho I'd keep 80 and 160 as defaults rather
than nil (the horizontal 160 seems very safe, I'm not quite as sure
about the vertical 80, but it seems OK for now).

> There's yet no clever default for
> handling the height/width aspect ratio.

Not sure what you mean.  Do you mean control the aspect ratio test,
rather than use a hardcoded implicit 1?  If so I think we can leave at
that for now, it's not clear that it'll be needed anyway.


        Stefan

Re: `split-window-preferred-horizontally'

[David Hansen]

On Sat, 07 Jun 2008 10:21:48 +0200 martin rudalics wrote:

>> That's how I would like it:
>>
>> If the *frame* is >= 160 chars wide
>>
>>   - if it is already (horizontally) split use the *other* window with
>>     all the `*-other-window' commands and `display-buffer'
>
> `split-window-preferred-function' should decide if and how to split the
> largest (or most recently used) window offered by `display-buffer'.  It
> cannot decide which window to use when _no_ window gets split.

But the commands named `*-other' should obviously use some *other*
window.  Actually the term "other window" is pretty well defined via the
command `other-window'.

>>   - otherwise split it horizontally.
>>
>> If the *frame* is < 160 chars wide do above with s/horizontally/vertically/
>> (as the default behavior already is).
>
> (defun my-spf (window)
>   (if (>= (frame-width (window-frame window)) 120)
>       (when (window-full-width-p window)
> 	(let ((split-width-threshold 120))
> 	  (split-window window nil t)))
>     (split-window)))
>
> seems to do what you want with a value of 120 - I can't test 160 here.

(setq split-window-preferred-function #'my-spf)

-> Making completion list...
  if: Attempt to split minibuffer window

David

Re: `split-window-preferred-horizontally'

[martin rudalics]

> But the commands named `*-other' should obviously use some *other*
> window.  Actually the term "other window" is pretty well defined via the
> command `other-window'.

My bad - I checked in a fix.  Please try again on robotron.

martin

Re: `split-window-preferred-horizontally'

[David Hansen]

On Sun, 08 Jun 2008 15:07:09 +0200 martin rudalics wrote:

>> But the commands named `*-other' should obviously use some *other*
>> window.  Actually the term "other window" is pretty well defined via the
>> command `other-window'.
>
> My bad - I checked in a fix.  Please try again on robotron.

Nice, and at a first glance it looks like `sensible' splitting is pretty
much doing what I want.

David

Re: `split-window-preferred-horizontally'

[David Hansen]

On Sun, 08 Jun 2008 19:49:36 +0200 David Hansen wrote:

> On Sun, 08 Jun 2008 15:07:09 +0200 martin rudalics wrote:
>
>>> But the commands named `*-other' should obviously use some *other*
>>> window.  Actually the term "other window" is pretty well defined via the
>>> command `other-window'.
>>
>> My bad - I checked in a fix.  Please try again on robotron.
>
> Nice, and at a first glance it looks like `sensible' splitting is pretty
> much doing what I want.

One annoyance left:  when I have one frame split horizontally, then enter
the minibuffer and something triggers display of completions, the
completions are displayed in the window that was active before i entered
the minibuffer.

IMHO completions should be displayed in the window that was the "other
window" before I entered the minibuffer (it does so with one vertically
split).

David

Re: `split-window-preferred-horizontally'

[martin rudalics]

 > One annoyance left:  when I have one frame split horizontally, then enter
 > the minibuffer and something triggers display of completions, the
 > completions are displayed in the window that was active before i entered
 > the minibuffer.

Thanks for spotting.  The bug occurs because I've been using
`with-selected-window' when trying to split the least recently used
window (the right window in your case) thus messing up that window's
use_time.  As a consequence the other window (the left window in your
case) becomes the least recently used one and gets selected for
displaying the completions.  I've checked in a fix, please try again.

I think `select-window' should avoid changing window_select_count when
norecord is non-nil but maybe this could have unwanted side-effects.

Re: `split-window-preferred-horizontally'

[Stefan Monnier]

> I think `select-window' should avoid changing window_select_count when
> norecord is non-nil

That sounds right.

> but maybe this could have unwanted side-effects.

I doubt it,


        Stefan