Patch: prefer-window-split-horizontally

Patch: prefer-window-split-horizontally

[Tassilo Horn]

Hi all,

I reworked Fredrik Axelsson's patch [1] since I couldn't contact him for
more than a month.  I think now would be a good time to include it.

It adds this new variable:

,----[ C-h v prefer-window-split-horizontally RET ]
| prefer-window-split-horizontally is a variable defined in `C source code'.
| Its value is t
| 
| 
| Documentation:
| *Non-nil means that windows are split horizontally, i.e. side-by-side, instead
| of vertically by `display-buffer'.
| An integer value means that windows may only be split horizontally if the newly
| created window is at least as wide as that value.
| 
| You can customize this variable.
| 
| [back]
`----

It works nicely here, but since I'm no appreciator of emacs internals
please have a close look at it.

Bye,
Tassilo
__________
[1] http://thread.gmane.org/gmane.emacs.pretest.bugs/17653

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

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

Hi again,

I forgot to attach the patch.


[-- Attachment #2: prefer-window-split-horizontally.patch --]
[-- Type: text/x-patch, Size: 6903 bytes --]

Index: src/window.c
===================================================================
RCS file: /sources/emacs/emacs/src/window.c,v
retrieving revision 1.584
diff -u -r1.584 window.c
--- src/window.c	13 Aug 2007 13:41:17 -0000	1.584
+++ src/window.c	14 Aug 2007 16:22:19 -0000
@@ -161,6 +161,13 @@
 
 Lisp_Object Veven_window_heights;
 
+/* Non-nil means that windows are split horizontally, i.e. side-by-side,
+   instead of vertically by `display-buffer'.  An integer value means that
+   windows may only be split horizontally if the newly created window is at
+   least as wide as that value.  */
+
+Lisp_Object Vprefer_window_split_horizontally;
+
 /* List of buffer *names* for buffers that should have their own frames.  */
 
 Lisp_Object Vspecial_display_buffer_names;
@@ -3647,7 +3654,12 @@
 
 If `even-window-heights' is non-nil, window heights will be evened out
 if displaying the buffer causes two vertically adjacent windows to be
-displayed.  */)
+displayed.
+
+If `prefer-window-split-horizontally' is non-nil, windows are split
+horizontally, i.e. side-by-side, instead of vertically if possible. If the
+variable has an integer value, windows may only be split horizontally if the
+newly created window is at least as wide as that value.  */)
      (buffer, not_this_window, frame)
      register Lisp_Object buffer, not_this_window, frame;
 {
@@ -3747,25 +3759,52 @@
       else
 	window = Fget_largest_window (frames, Qt);
 
+      /* If we prefer to split horizontally and if the resulting window would be
+         wide enough, split it horizontally.  */
+      if (!NILP (window)
+          && !NILP (Vprefer_window_split_horizontally)
+          && ! FRAME_NO_SPLIT_P (XFRAME (XWINDOW (window)->frame))
+          && WINDOW_FULL_WIDTH_P (XWINDOW (window))
+          && (window_width(window) >> 1) >= window_min_width
+          && (!NUMBERP (Vprefer_window_split_horizontally) ||
+              (window_width(window) >> 1) >= XINT (Vprefer_window_split_horizontally)))
+	{
+	  window = Fsplit_window (window, Qnil, Qt);
+	}
+
       /* If the largest window is tall enough, full-width, and either eligible
 	 for splitting or the only window, split it.  */
-      if (!NILP (window)
-	  && ! FRAME_NO_SPLIT_P (XFRAME (XWINDOW (window)->frame))
-	  && WINDOW_FULL_WIDTH_P (XWINDOW (window))
-	  && (window_height (window) >= split_height_threshold
-	      || (NILP (XWINDOW (window)->parent)))
-	  && (window_height (window)
-	      >= (2 * window_min_size_2 (XWINDOW (window), 0))))
+      else if (!NILP (window)
+	       && ! FRAME_NO_SPLIT_P (XFRAME (XWINDOW (window)->frame))
+	       && WINDOW_FULL_WIDTH_P (XWINDOW (window))
+	       && (window_height (window) >= split_height_threshold
+		   || (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, lower, other;
 
 	  window = Fget_lru_window (frames, Qt);
-	  /* If the LRU window is tall enough, and either eligible for splitting
-	  and selected or the only window, split it.  */
+	  /* If the LRU window is selected, and we prefer to split horizontally
+	     and it's big enough, and can be split, split it horizontally.  */
 	  if (!NILP (window)
 	      && ! FRAME_NO_SPLIT_P (XFRAME (XWINDOW (window)->frame))
+	      && (EQ (window, selected_window)
+		  || EQ (XWINDOW (window)->parent, Qnil))
+              && !NILP (Vprefer_window_split_horizontally)
+              && (window_width(window) >> 1) >= window_min_width
+              && (!NUMBERP (Vprefer_window_split_horizontally) ||
+                  (window_width(window) >> 1) >= XINT (Vprefer_window_split_horizontally)))
+	    {
+	      window = Fsplit_window (window, Qnil, Qt);
+	    }
+
+	  /* If the LRU window is tall enough, and either eligible for splitting
+	     and selected or the only window, split it.  */
+	  else if (!NILP (window)
+	      && ! FRAME_NO_SPLIT_P (XFRAME (XWINDOW (window)->frame))
 	      && ((EQ (window, selected_window)
 		   && window_height (window) >= split_height_threshold)
 		  || (NILP (XWINDOW (window)->parent)))
@@ -7344,6 +7383,13 @@
 If nil, `display-buffer' will leave the window configuration alone.  */);
   Veven_window_heights = Qt;
 
+  DEFVAR_LISP ("prefer-window-split-horizontally", &Vprefer_window_split_horizontally,
+	       doc: /* *Non-nil means that windows are split horizontally, i.e. side-by-side, instead
+of vertically by `display-buffer'.
+An integer value means that windows may only be split horizontally if the newly
+created window is at least as wide as that value.  */);
+  Vprefer_window_split_horizontally = Qnil;
+
   DEFVAR_LISP ("minibuffer-scroll-window", &Vminibuf_scroll_window,
 	       doc: /* Non-nil means it is the window that C-M-v in minibuffer should scroll.  */);
   Vminibuf_scroll_window = Qnil;
Index: src/ChangeLog
===================================================================
RCS file: /sources/emacs/emacs/src/ChangeLog,v
retrieving revision 1.5785
diff -u -r1.5785 ChangeLog
--- src/ChangeLog	13 Aug 2007 13:41:12 -0000	1.5785
+++ src/ChangeLog	14 Aug 2007 16:23:07 -0000
@@ -1,3 +1,10 @@
+2007-08-14  Tassilo Horn  <tassilo@member.fsf.org>
+
+	* window.c (prefer_window_split_horizontally): New variable.
+	Rework of Fredrik Axelsson's patch.  See
+	http://thread.gmane.org/gmane.emacs.pretest.bugs/17653.
+	(display_buffer): Consider splitting windows horizontally.
+
 2007-08-13  Jan Djärv  <jan.h.d@swipnet.se>
 
 	* gtkutil.c (update_frame_tool_bar): Use -1 as index
Index: lisp/cus-start.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/cus-start.el,v
retrieving revision 1.104
diff -u -r1.104 cus-start.el
--- lisp/cus-start.el	26 Jul 2007 05:26:19 -0000	1.104
+++ lisp/cus-start.el	14 Aug 2007 16:23:08 -0000
@@ -350,6 +350,7 @@
  		       (const :tag "Full screen (t)" :value t)
  		       (other :tag "Always" 1)))
 	     (display-buffer-reuse-frames windows boolean "21.1")
+	     (prefer-window-split-horizontally windows (choice boolean integer) "22.1")
 	     ;; xdisp.c
 	     (scroll-step windows integer)
 	     (scroll-conservatively windows integer)
Index: lisp/ChangeLog
===================================================================
RCS file: /sources/emacs/emacs/lisp/ChangeLog,v
retrieving revision 1.11548
diff -u -r1.11548 ChangeLog
--- lisp/ChangeLog	14 Aug 2007 14:52:51 -0000	1.11548
+++ lisp/ChangeLog	14 Aug 2007 16:23:15 -0000
@@ -1,3 +1,9 @@
+2007-08-14  Tassilo Horn  <tassilo@member.fsf.org>
+
+	* cus-start.el (all): Add prefer-window-split-horizontally from
+	window.c.  Rework of Fredrik Axelsson's patch.  See
+	http://thread.gmane.org/gmane.emacs.pretest.bugs/17653.
+
 2007-08-14  Chris Hecker  <checker@d6.com> (tiny change)
 
 	* calc/calc-aent.el (calc-do-quick-calc): Add binary

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


Bye,
Tassilo

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch: prefer-window-split-horizontally

[Richard Stallman]

    +2007-08-14  Tassilo Horn  <tassilo@member.fsf.org>
    +
    +	* window.c (prefer_window_split_horizontally): New variable.
    +	Rework of Fredrik Axelsson's patch.  See
    +	http://thread.gmane.org/gmane.emacs.pretest.bugs/17653.
    +	(display_buffer): Consider splitting windows horizontally.

If nontrivial code remains from his patch, his name needs to appear in
the header along with yours.  And we need legal papers from him,
which we didn't have as of a week ago.

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     +2007-08-14  Tassilo Horn  <tassilo@member.fsf.org>
>     +
>     +	* window.c (prefer_window_split_horizontally): New variable.
>     +	Rework of Fredrik Axelsson's patch.  See
>     +	http://thread.gmane.org/gmane.emacs.pretest.bugs/17653.
>     +	(display_buffer): Consider splitting windows horizontally.
>
> If nontrivial code remains from his patch, his name needs to appear in
> the header along with yours.

All nontrivial code is from him.

> And we need legal papers from him, which we didn't have as of a week
> ago.

Oh, ok.  Then we have to wait for him anyway.

Bye,
Tassilo

Re: Patch: prefer-window-split-horizontally

[Richard Stallman]

What is Axelsson's email adddress?

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

> What is Axelsson's email adddress?

"Fredrik Axelsson" <f.axelsson@gmail.com>

Bye,
Tassilo

Re: Patch: prefer-window-split-horizontally

[Juri Linkov]

> I reworked Fredrik Axelsson's patch [1] since I couldn't contact him for
> more than a month.  I think now would be a good time to include it.
>
> It adds this new variable:
> ,----[ C-h v prefer-window-split-horizontally RET ]
> | prefer-window-split-horizontally is a variable defined in `C source code'.
> | Its value is t
> | 
> | Documentation:
> | *Non-nil means that windows are split horizontally, i.e. side-by-side, instead
> | of vertically by `display-buffer'.
> | An integer value means that windows may only be split horizontally if the newly
> | created window is at least as wide as that value.

What do you think about adding another variable `split-window-function'
with the default value `split-window-vertically' or nil with the same
meaning, and the possible other value `split-window-horizontally'?
This would be like setting `ediff-split-window-function' to
`split-window-horizontally'.

Since this value will hold a function we can set it to any function
that implements different heuristics to decide how to split the window:
whether to take into account the window size or the window name, etc.

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

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

> What do you think about adding another variable
> `split-window-function' with the default value
> `split-window-vertically' or nil with the same meaning, and the
> possible other value `split-window-horizontally'?  This would be like
> setting `ediff-split-window-function' to `split-window-horizontally'.
>
> Since this value will hold a function we can set it to any function
> that implements different heuristics to decide how to split the
> window: whether to take into account the window size or the window
> name, etc.

I would be happy with that, too.  Well, I think it's even better.  But
we really should come up with some mechanism to utilize the widescreen
displays computers nowadays have.

I think your approach would do that.  This example function would split
horizontally as long as all windows are 80 or more columns wide.

--8<---------------cut here---------------start------------->8---
(defun th-split-window-function ()
  (save-window-excursion
    (save-excursion
      (split-window-horizontally)
      (balance-windows)
      (if (>= (let ((edges (window-edges))) (- (nth 2 edges) (nth 0 edges))) 80)
          'split-window-horizontally
        'split-window-vertically))))
--8<---------------cut here---------------end--------------->8---

Would you try to implement that?

Bye,
Tassilo

Re: Patch: prefer-window-split-horizontally

[Davis Herring]

> I think your approach would do that.  This example function would split
> horizontally as long as all windows are 80 or more columns wide.
>
> --8<---------------cut here---------------start------------->8---
> (defun th-split-window-function ()
>   (save-window-excursion
>     (save-excursion
>       (split-window-horizontally)
>       (balance-windows)
>       (if (>= (let ((edges (window-edges))) (- (nth 2 edges) (nth 0
> edges))) 80)
>           'split-window-horizontally
>         'split-window-vertically))))
> --8<---------------cut here---------------end--------------->8---
>
> Would you try to implement that?

Splitting one window should not involve destroying all Lisp references to
existing windows (as `save-window-excursion' must).  Unless redisplay
would somehow be supressed here (I'm not sure), this would also involve
calling `window-size-change-functions' twice for each split, which would
be wasteful and perhaps confusing.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

"Davis Herring" <herring@lanl.gov> writes:

Hi Davis,

>> I think your approach would do that.  This example function would split
>> horizontally as long as all windows are 80 or more columns wide.
>>
>> --8<---------------cut here---------------start------------->8---
>> (defun th-split-window-function ()
>>   (save-window-excursion
>>     (save-excursion
>>       (split-window-horizontally)
>>       (balance-windows)
>>       (if (>= (let ((edges (window-edges))) (- (nth 2 edges) (nth 0
>> edges))) 80)
>>           'split-window-horizontally
>>         'split-window-vertically))))
>> --8<---------------cut here---------------end--------------->8---
>>
>> Would you try to implement that?
>
> Splitting one window should not involve destroying all Lisp references
> to existing windows (as `save-window-excursion' must).  Unless
> redisplay would somehow be supressed here (I'm not sure), this would
> also involve calling `window-size-change-functions' twice for each
> split, which would be wasteful and perhaps confusing.

Is there another way to figure out how wide the windows that would
result from a horizontal split would be?

And if you want to avoid the problems you mentioned, you could go with:

--8<---------------cut here---------------start------------->8---
(defun th-split-window-function ()
  (if (>= (let ((edges (window-edges)))
            (- (nth 2 edges) (nth 0 edges)))
          162)
      'split-window-horizontally
    'split-window-vertically))
--8<---------------cut here---------------end--------------->8---

I don't use scroll bars, so if the current window is 162 columns wide a
horizontal split will result in two 80 column wide windows.  Two columns
will be occupied by the additional fringe.

Anyway, I like Juri's suggestion because it gives the user a very good
control over splitting decisions.

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Patch: prefer-window-split-horizontally

[Richard Stallman]

    What do you think about adding another variable `split-window-function'
    with the default value `split-window-vertically' or nil with the same
    meaning, and the possible other value `split-window-horizontally'?
    This would be like setting `ediff-split-window-function' to
    `split-window-horizontally'.

It seems like overfeaturism to me.

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

>     What do you think about adding another variable
>     `split-window-function' with the default value
>     `split-window-vertically' or nil with the same meaning, and the
>     possible other value `split-window-horizontally'?  This would be
>     like setting `ediff-split-window-function' to
>     `split-window-horizontally'.
>
> It seems like overfeaturism to me.

I don't think so.  Although I don't know emacs internals very much, the
changes shouldn't be too big, e.g. modify `split-window' so that it
splits according the return value of `split-window-function' if no other
args except WINDOW are given.

And I think that the function in `split-window-function' should return
any symbol naming a function instead of only `split-window-vertically'
and `split-window-vertically'.  `split-window' could then funcall it.

I'd like to define functions such as
`split-window-horizontally-and-balance'.

What do you think?

Bye,
Tassilo
-- 
Once you go Norris, you are physically unable to go back. 

Re: Patch: prefer-window-split-horizontally

[Stefan Monnier]

> What do you think about adding another variable `split-window-function'
> with the default value `split-window-vertically' or nil with the same
> meaning, and the possible other value `split-window-horizontally'?
> This would be like setting `ediff-split-window-function' to
> `split-window-horizontally'.

Just for the record: we're talking about something used only in
display-buffer so a name like `split-window-function' doesn't seem right.

And we already have display-buffer-function, which makes it possible to
customize the way the windows are split.  Now customizing
display-buffer-function is not always easy, so maybe
prefer-window-split-horizontally makes sense, or maybe we should simply
change the default behavior of display-buffer to do the suggested "if
current window is very wide, split it horizontally rather than vertically"
and not introduce any new customization (or maybe just a "ideal columns" or
"ideal aspect-ratio" based on which we decide whether to split vertically
rather than horizontally).


        Stefan

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

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

Hi Stefan,

>> What do you think about adding another variable
>> `split-window-function' with the default value
>> `split-window-vertically' or nil with the same meaning, and the
>> possible other value `split-window-horizontally'?  This would be like
>> setting `ediff-split-window-function' to `split-window-horizontally'.
>
> Just for the record: we're talking about something used only in
> display-buffer so a name like `split-window-function' doesn't seem
> right.

The suggested variable's function could be used in `split-window',
couldn't it?

In <87bqd8vd6j.fsf@baldur.tsdh.de> I suggested that the function
assigned to `split-window-function' should return a symbol naming the
function that does the split.  So one could define splitting heuristics
like "split horizontally as long as each window is more than 80 columns
wide after balancing".  I don't know if it's feasible, but I really like
the possibilities it offers.

Bye,
Tassilo

Re: Patch: prefer-window-split-horizontally

[Stefan Monnier]

>>> What do you think about adding another variable
>>> `split-window-function' with the default value
>>> `split-window-vertically' or nil with the same meaning, and the
>>> possible other value `split-window-horizontally'?  This would be like
>>> setting `ediff-split-window-function' to `split-window-horizontally'.
>> 
>> Just for the record: we're talking about something used only in
>> display-buffer so a name like `split-window-function' doesn't seem
>> right.

> The suggested variable's function could be used in `split-window',
> couldn't it?

Sounds more delicate: split-window is a lower-level function used by several
other pieces of code that want to have precise control over the layout of
windows inside a frame (e.g. Gnus).


        Stefan

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

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

Hi Stefan,

>>> Just for the record: we're talking about something used only in
>>> display-buffer so a name like `split-window-function' doesn't seem
>>> right.
>
>> The suggested variable's function could be used in `split-window',
>> couldn't it?
>
> Sounds more delicate: split-window is a lower-level function used by
> several other pieces of code that want to have precise control over
> the layout of windows inside a frame (e.g. Gnus).

Since `split-window-function' would default to `split-window-vertically'
it shouldn't make a difference.  And of course `split-window-function'
may only be used in `split-window' if its parameters SIZE and HORFLAG
are omitted.

Do you think there are packages that would still be break on this?  If
yes, then maybe the packages should be adapted to the new behavior (by
adding the required params to `split-window' if they need fine grained
control) and not the other way around.

Bye,
Tassilo

Re: Patch: prefer-window-split-horizontally

[Stefan Monnier]

>>>> Just for the record: we're talking about something used only in
>>>> display-buffer so a name like `split-window-function' doesn't seem
>>>> right.
>> 
>>> The suggested variable's function could be used in `split-window',
>>> couldn't it?
>> 
>> Sounds more delicate: split-window is a lower-level function used by
>> several other pieces of code that want to have precise control over
>> the layout of windows inside a frame (e.g. Gnus).

> Since `split-window-function' would default to `split-window-vertically'
> it shouldn't make a difference.  And of course `split-window-function'
> may only be used in `split-window' if its parameters SIZE and HORFLAG
> are omitted.

> Do you think there are packages that would still be break on this?  If
> yes, then maybe the packages should be adapted to the new behavior (by
> adding the required params to `split-window' if they need fine grained
> control) and not the other way around.

Changing the behavior of split-window so that it uses something like
split-window-function only makes sense if we want to change the behavior
seen by current callers of this function.  If all/most current callers of
this function would rather have it stay the way it is and if all callers
that want it changed do not call it directly (or call it interactively),
then we're better off changing the other place where split-window is called
(i.e. display-buffer) or creating a new function.


        Stefan

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

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

>> Since `split-window-function' would default to
>> `split-window-vertically' it shouldn't make a difference.  And of
>> course `split-window-function' may only be used in `split-window' if
>> its parameters SIZE and HORFLAG are omitted.
>
>> Do you think there are packages that would still be break on this?
>> If yes, then maybe the packages should be adapted to the new behavior
>> (by adding the required params to `split-window' if they need fine
>> grained control) and not the other way around.
>
> Changing the behavior of split-window so that it uses something like
> split-window-function only makes sense if we want to change the
> behavior seen by current callers of this function.

That's the case, isn't it?  And the behavior would only change if users
modify `split-window-function'.  So I don't see a problem here.

> If all/most current callers of this function would rather have it stay
> the way it is and if all callers that want it changed do not call it
> directly (or call it interactively), then we're better off changing
> the other place where split-window is called (i.e. display-buffer) or
> creating a new function.

I cannot follow you completely.  In most cases it's not the caller who
should decide how windows are split but the user, who wants to use his
screen as good as possible.

Beside Gnus and ECB I don't know any packages that have to care of how
windows have to be split.  And at least for Gnus I can say that it does
the split using all params `split-window' has, and thus
`split-window-function' wouldn't be used.

Bye,
Tassilo

RE: Patch: prefer-window-split-horizontally

[klaus.berndl]

Tassilo Horn wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> Since `split-window-function' would default to
>>> `split-window-vertically' it shouldn't make a difference.  And of
>>> course `split-window-function' may only be used in `split-window' if
>>> its parameters SIZE and HORFLAG are omitted.
>> 
>>> Do you think there are packages that would still be break on this?
>>> If yes, then maybe the packages should be adapted to the new
>>> behavior (by adding the required params to `split-window' if they
>>> need fine grained control) and not the other way around.
>> 
>> Changing the behavior of split-window so that it uses something like
>> split-window-function only makes sense if we want to change the
>> behavior seen by current callers of this function.
> 
> That's the case, isn't it?  And the behavior would only change if
> users modify `split-window-function'.  So I don't see a problem here.
> 
>> If all/most current callers of this function would rather have it
>> stay the way it is and if all callers that want it changed do not
>> call it directly (or call it interactively), then we're better off
>> changing the other place where split-window is called (i.e.
>> display-buffer) or creating a new function.
> 
> I cannot follow you completely.  In most cases it's not the caller who
> should decide how windows are split but the user, who wants to use his
> screen as good as possible.
> 
> Beside Gnus and ECB I don't know any packages that have to care of how
> windows have to be split.  And at least for Gnus I can say that it
> does the split using all params `split-window' has, and thus
> `split-window-function' wouldn't be used.

If it's usefull for you, i can check this for ECB - can you please
repeat exactly what i have to check! Then i can do this at weekend...

Klaus

> 
> Bye,
> Tassilo
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

<klaus.berndl@sdm.de> writes:

Hi Klaus,

>>> If all/most current callers of this function would rather have it
>>> stay the way it is and if all callers that want it changed do not
>>> call it directly (or call it interactively), then we're better off
>>> changing the other place where split-window is called (i.e.
>>> display-buffer) or creating a new function.
>> 
>> I cannot follow you completely.  In most cases it's not the caller
>> who should decide how windows are split but the user, who wants to
>> use his screen as good as possible.
>> 
>> Beside Gnus and ECB I don't know any packages that have to care of
>> how windows have to be split.  And at least for Gnus I can say that
>> it does the split using all params `split-window' has, and thus
>> `split-window-function' wouldn't be used.
>
> If it's usefull for you, i can check this for ECB - can you please
> repeat exactly what i have to check! Then i can do this at weekend...

I suggested to change `split-window' so that it splits in a way the user
can configure by setting `split-window-function' to a function that
returns a symbol naming a function that should do the split, if and only
if split-window is called with zero or one (the WINDOW) argument.  So
calls to `split-window' that rely on the current behavior (that the
split will be vertically) are forced to use the additional parameters.

So if ECB relies on the current behavior, calls like

   (split-window window)

might not do what you expect if the user configured
`split-window-function'.

I grepped ECB's code and there are at least 4 places that would need to
be adapted.

./ecb-layout.el:2213:                       (setq window (split-window window))
./ecb-layout.el:2227:                           (setq window (split-window window)))
./ecb-layout.el:2955:                    (split-window (car (ecb-canonical-edit-windows-list)))))
./ecb-layout.el:2991:                    (split-window (car edit-win-list)))))
./ecb-layout.el:3757:   (call-interactively 'split-window)))

BTW: I see a problem with my approach.  I guess in elisp the calls

     (split-window window)

and

     (split-window window nil nil)

are equal and you cannot distinguish if nil was given explicitly or not,
right?

So maybe the HORFLAG argument should be changed to FLAG with possible
values 'horizontal and 'vertical, defaulting to 'horizontal.  I guess
that wouldn't break most current packages, because you normally wouldn't
give all args if they're nil.  Of course, calls like

     (split-window window size (want-horiz))

where the FLAG is calculated would need to be checked.

Bye,
Tassilo

Re: Patch: prefer-window-split-horizontally

[Stefan Monnier]

>> Changing the behavior of split-window so that it uses something like
>> split-window-function only makes sense if we want to change the
>> behavior seen by current callers of this function.

> That's the case, isn't it?

Is it, really?  As far as I can tell, you only want to change the behavior
in the following cases: when called from display-buffer and when
called interactively.  Since split-window has currently no key-binding,
calling it interactively is not very common and we can just as well create
a new command split-window-sensibly which obeys
split-window-sensibly-function (and then have display-buffer use this
function as well).

> And the behavior would only change if users modify
> `split-window-function'.  So I don't see a problem here.

Think of those users who want a fancy split-window-function for
display-buffer but still want the layout of their
Gnus/ECB/MPC/GUD/ProofGeneral/... to appear correctly without having to
tweak their source code or beg the authors to adapt their code to the
new behavior.

> I cannot follow you completely.  In most cases it's not the caller who
> should decide how windows are split but the user, who wants to use his
> screen as good as possible.

Yes, in *most* cases, maybe, but not all.  Better have two separate function
for the two separate cases.

> Beside Gnus and ECB I don't know any packages that have to care of how
> windows have to be split.

There are plenty.  I'd guess that most callers of split-window care
about it because most of those that don't care prefer to use
pop-to-buffer/display-buffer so that not only do they not have to care how
it's split, but they don't even have to care if it's split at all or if
another frame is used.
Try a "grep split-window" in the lisp sources.


        Stefan

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

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

>>> Changing the behavior of split-window so that it uses something like
>>> split-window-function only makes sense if we want to change the
>>> behavior seen by current callers of this function.
>
>> That's the case, isn't it?
>
> Is it, really?  As far as I can tell, you only want to change the
> behavior in the following cases: when called from display-buffer and
> when called interactively.  Since split-window has currently no
> key-binding, calling it interactively is not very common and we can
> just as well create a new command split-window-sensibly which obeys
> split-window-sensibly-function (and then have display-buffer use this
> function as well).

Indeed, you're right.  So I suggest to do it that way.

>> And the behavior would only change if users modify
>> `split-window-function'.  So I don't see a problem here.
>
> Think of those users who want a fancy split-window-function for
> display-buffer but still want the layout of their
> Gnus/ECB/MPC/GUD/ProofGeneral/... to appear correctly without having
> to tweak their source code or beg the authors to adapt their code to
> the new behavior.

Look at Klaus.  He's begging to adapt his code. ;-)

>> I cannot follow you completely.  In most cases it's not the caller
>> who should decide how windows are split but the user, who wants to
>> use his screen as good as possible.
>
> Yes, in *most* cases, maybe, but not all.  Better have two separate
> function for the two separate cases.

Agreed.  And it still gives users all possibilities they need.

Bye,
Tassilo

RE: Patch: prefer-window-split-horizontally

[klaus.berndl]

Tassilo Horn wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>>> Changing the behavior of split-window so that it uses something
>>>> like split-window-function only makes sense if we want to change
>>>> the behavior seen by current callers of this function.
>> 
>>> That's the case, isn't it?
>> 
>> Is it, really?  As far as I can tell, you only want to change the
>> behavior in the following cases: when called from display-buffer and
>> when called interactively.  Since split-window has currently no
>> key-binding, calling it interactively is not very common and we can
>> just as well create a new command split-window-sensibly which obeys
>> split-window-sensibly-function (and then have display-buffer use this
>> function as well).
> 
> Indeed, you're right.  So I suggest to do it that way.
> 
>>> And the behavior would only change if users modify
>>> `split-window-function'.  So I don't see a problem here.
>> 
>> Think of those users who want a fancy split-window-function for
>> display-buffer but still want the layout of their
>> Gnus/ECB/MPC/GUD/ProofGeneral/... to appear correctly without having
>> to tweak their source code or beg the authors to adapt their code to
>> the new behavior.
> 
> Look at Klaus.  He's begging to adapt his code. ;-)

then you have completely misunderstood my posting ;-)
i just offered to *check* if there could be problems within ECB...
adapting is a complete other chapter ;-)

> 
>>> I cannot follow you completely.  In most cases it's not the caller
>>> who should decide how windows are split but the user, who wants to
>>> use his screen as good as possible.
>> 
>> Yes, in *most* cases, maybe, but not all.  Better have two separate
>> function for the two separate cases.
> 
> Agreed.  And it still gives users all possibilities they need.
> 
> Bye,
> Tassilo
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch: prefer-window-split-horizontally

[Juri Linkov]

>> What do you think about adding another variable `split-window-function'
>> with the default value `split-window-vertically' or nil with the same
>> meaning, and the possible other value `split-window-horizontally'?
>> This would be like setting `ediff-split-window-function' to
>> `split-window-horizontally'.
>
> Just for the record: we're talking about something used only in
> display-buffer so a name like `split-window-function' doesn't seem right.

display-buffer splits windows, so it could use `split-window-function'
to decide how to split.

> And we already have display-buffer-function, which makes it possible to
> customize the way the windows are split.  Now customizing
> display-buffer-function is not always easy,

There was an idea to rewrite the whole `display-buffer' in Lisp, and make
it more customizable.  But it seems it is impossible to rewrite it
completely, because the current C implementation processes its input
argument `frame' which isn't given to display-buffer-function:

    return call2 (Vdisplay_buffer_function, buffer, not_this_window);

which is called with `buffer' and `not_this_window', but not `frame'.

> so maybe prefer-window-split-horizontally makes sense, or maybe we
> should simply change the default behavior of display-buffer to do the
> suggested "if current window is very wide, split it horizontally rather
> than vertically" and not introduce any new customization (or maybe just
> a "ideal columns" or "ideal aspect-ratio" based on which we decide
> whether to split vertically rather than horizontally).

Maybe, this is possible.  For instance, "ideal columns" could be the same
as `fill-column' or some other number near 80 columns.

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

Re: Patch: prefer-window-split-horizontally

[Stefan Monnier]

> There was an idea to rewrite the whole `display-buffer' in Lisp, and make
> it more customizable.  But it seems it is impossible to rewrite it
> completely, because the current C implementation processes its input
> argument `frame' which isn't given to display-buffer-function:

>     return call2 (Vdisplay_buffer_function, buffer, not_this_window);

> which is called with `buffer' and `not_this_window', but not `frame'.

Sounds like a bug to fix,


        Stefan

Re: Patch: prefer-window-split-horizontally

[Juri Linkov]

>> There was an idea to rewrite the whole `display-buffer' in Lisp, and make
>> it more customizable.  But it seems it is impossible to rewrite it
>> completely, because the current C implementation processes its input
>> argument `frame' which isn't given to display-buffer-function:
>
>>     return call2 (Vdisplay_buffer_function, buffer, not_this_window);
>
>> which is called with `buffer' and `not_this_window', but not `frame'.
>
> Sounds like a bug to fix,

Adding a new argument will break existing implementations of
display-buffer-function in user programs and .emacs files.  I'm sure
they all have only two arguments, and calling them with three arguments
will fail.

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

Re: Patch: prefer-window-split-horizontally

[Richard Stallman]

    There was an idea to rewrite the whole `display-buffer' in Lisp, and make
    it more customizable.  But it seems it is impossible to rewrite it
    completely, because the current C implementation processes its input
    argument `frame' which isn't given to display-buffer-function:

So what?  How does that stop us from replacing the C code with Lisp code?

Re: Patch: prefer-window-split-horizontally

[Juri Linkov]

>     There was an idea to rewrite the whole `display-buffer' in Lisp, and make
>     it more customizable.  But it seems it is impossible to rewrite it
>     completely, because the current C implementation processes its input
>     argument `frame' which isn't given to display-buffer-function:
>
> So what?  How does that stop us from replacing the C code with Lisp code?

Actually this stop us from duplicating Fdisplay_buffer in Lisp as a
function that is called via `display-buffer-function' from the C function
Fdisplay_buffer (because we can't add a new argument `frame' which will break
existing user functions called via `display-buffer-function'), but this
doesn't stop us from replacing the whole C function `Fdisplay_buffer' with
Lisp code.

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

Re: Patch: prefer-window-split-horizontally

[Dieter Wilhelm]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Hi all,
>
> I reworked Fredrik Axelsson's patch [1] since I couldn't contact him for
> more than a month.  I think now would be a good time to include it.
>
> It adds this new variable:
>
> ,----[ C-h v prefer-window-split-horizontally RET ]

...
> __________
> [1] http://thread.gmane.org/gmane.emacs.pretest.bugs/17653

I'd very appreciate this inclusion, thanks.

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: Patch: prefer-window-split-horizontally

[Tassilo Horn]

Dieter Wilhelm <dieter@duenenhof-wilhelm.de> writes:

Hi Dieter,

>> I reworked Fredrik Axelsson's patch [1] since I couldn't contact him for
>> more than a month.  I think now would be a good time to include it.
>>
>> It adds this new variable:
>>
>> ,----[ C-h v prefer-window-split-horizontally RET ]
>
> ...
>> __________
>> [1] http://thread.gmane.org/gmane.emacs.pretest.bugs/17653
>
> I'd very appreciate this inclusion, thanks.

IMO Juri's suggestion (<87vebij5p8.fsf@jurta.org>) is even better
because it's more generic.  The drawback is that it's not already
implemented. :-)

Bye,
Tassilo
-- 
The glass is neither half-full nor half-empty: it's twice as big as it
needs to be.