unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 20189@debbugs.gnu.org
Subject: bug#20189: 25.0.50; Feature request: Alternative split-window-sensibly functions
Date: Wed, 25 Mar 2015 10:41:19 +0100	[thread overview]
Message-ID: <87k2y51kjk.fsf@gnu.org> (raw)
In-Reply-To: <87iodqbvoz.fsf@gnu.org>

martin rudalics <rudalics@gmx.at> writes:

>> two consecutive C-x 3 starting from the big single window results in
>> three side-by-side *balanced* windows, each being 86x82 large.
>> That's actually what I wanted.  However, I'd like that this splitting
>> behavior was the default for `display-buffer'.  But that fails
>> because after the first horizontal split, `window-splittable-p' says
>> that both horizontal windows aren't horizontally splittable anymore
>> because they are narrower than `split-width-threshold'.
>
> If you set `split-width-threshold' to zero and
> `split-height-threshold' to nil you should get the behavior you want.

Wouldn't that mean that I get as many horizontal windows until they
become smaller than `window-min-width'?  I want them to alway be at
least 80 columns wide.

>> I've come up with a solution which seems to fit my preferences quite
>> nicely although it's probably quite hackish and ignores possible
>> contracts that might exist for dedicated windows, fixed-size windows,
>> side windows and what else there might be.
>
> You should be able to simplify your code by using idioms from the
> below.
>
> (defun th/split-window-sensibly (_window)
>   (let ((root (frame-root-window))
> 	(window-combination-resize 'resize))
>     (cond
>      ((>= (/ (window-total-width root) (window-combinations root t)) 80)
>       (split-window (window-last-child root) nil 'right))
>      ((>= (/ (window-total-height root) (window-combinations root)) 40)
>       (split-window (window-last-child root) nil 'below))
>      (t
>       (split-window-sensibly window)))))

With that and repeated `display-buffer' calls for different buffers
starting with a single 269x82 window, I get 3 balanced side-by-side
windows first (good!), but the next d-b creates another horizontal
window.  Then I have 4 side-by-side balanced windows where each one is
less than 80 columns wide.  And yet another d-b splits the rightmost
window vertically although I don't want vertical splits at all if there
are already horizontal splits.  In that case, it should have reused some
existing window.

Here's my test case:

--8<---------------cut here---------------start------------->8---
(defun th/split-window-sensibly (_window)
  (let ((root (frame-root-window))
 	(window-combination-resize 'resize))
    (cond
     ((>= (/ (window-total-width root) (window-combinations root t)) 80)
      (split-window (window-last-child root) nil 'right))
     ((>= (/ (window-total-height root) (window-combinations root)) 40)
      (split-window (window-last-child root) nil 'below))
     (t
      (split-window-sensibly window)))))

(setq split-window-preferred-function #'th/split-window-sensibly)

(defun test-splitting ()
  (interactive)
  (display-buffer (get-buffer-create "ONE"))
  (display-buffer (get-buffer-create "TWO"))
  (display-buffer (get-buffer-create "THREE"))
  (display-buffer (get-buffer-create "FOUR")))
--8<---------------cut here---------------end--------------->8---

So now when starting with emacs -Q, maximizing, putting the above in
*scratch*, evaling it, followed by M-x test-splitting RET, I get:

 +---------------+-------------+---------------+-------------+
 |               |             |               |             |
 |               |             |               |             |
 |               |             |               |             |
 |               |             |               |             |
 |               |             |               |             |
 |               |             |               |   THREE     |
 |               |             |               +-------------+
 |               |             |               |             |
 |               |             |               |             |
 |               |             |               |             |
 |               |             |               |             |
 | *scratch*     |    ONE      |    TWO        |   FOUR      |
 +---------------+-------------+---------------+-------------+

With my function, I get instead

 +--------------------+--------------------+-----------------+
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |   (ONE)         |
 |                    |                    |   (THREE)       |
 |    *scratch*       |     TWO            |    FOUR         |
 +--------------------+--------------------+-----------------+

where the (ONE), (THREE) denotes the buffer history, e.g., initially the
leftmost window showed buffer ONE, then it was reused to show THREE, and
finally it was reused again to show buffer FOUR.

That's ok for me although I think I'd like it better if it was this way:

 +--------------------+--------------------+-----------------+
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |                 |
 |                    |                    |   (TWO)         |
 |                    |                    |   (THREE)       |
 |    *scratch*       |     ONE            |    FOUR         |
 +--------------------+--------------------+-----------------+

Bye,
Tassilo





  reply	other threads:[~2015-03-25  9:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24  9:18 bug#20189: 25.0.50; Feature request: Alternative split-window-sensibly functions Tassilo Horn
2015-03-24 10:51 ` martin rudalics
2015-03-24 11:39   ` Tassilo Horn
2015-03-24 13:30     ` martin rudalics
2015-03-24 14:59       ` Tassilo Horn
2015-03-25  8:23         ` martin rudalics
2015-03-25  9:41           ` Tassilo Horn [this message]
2015-03-26 10:58             ` martin rudalics
2015-03-26 11:01             ` Tassilo Horn
2015-03-26 13:47               ` martin rudalics
2015-03-26 14:18                 ` Stefan Monnier
2015-03-26 14:31                   ` martin rudalics
2015-03-27 18:26                     ` Stefan Monnier
2015-03-26 15:15                 ` Tassilo Horn
2015-03-26 16:04                   ` martin rudalics
2015-03-24 17:05 ` Eli Zaretskii
2015-03-25  7:00   ` Tassilo Horn
2015-03-25  8:24     ` martin rudalics
2015-03-25 17:25     ` Eli Zaretskii
2015-03-25 19:33       ` Tassilo Horn
2015-03-25 19:38         ` Eli Zaretskii
2015-03-26  4:27           ` Tassilo Horn
2015-03-26 10:58             ` martin rudalics
2015-03-26 16:29             ` Eli Zaretskii
2015-03-25  8:23   ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2y51kjk.fsf@gnu.org \
    --to=tsdh@gnu.org \
    --cc=20189@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).