From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20189: 25.0.50; Feature request: Alternative split-window-sensibly functions Date: Tue, 24 Mar 2015 19:05:35 +0200 Message-ID: <83384uqqao.fsf@gnu.org> References: <87iodqbvoz.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427216798 15313 80.91.229.3 (24 Mar 2015 17:06:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Mar 2015 17:06:38 +0000 (UTC) Cc: 20189@debbugs.gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 24 18:06:28 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YaSHT-00059Z-TU for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Mar 2015 18:06:20 +0100 Original-Received: from localhost ([::1]:33596 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaSHT-0007dM-6e for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Mar 2015 13:06:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaSHI-0007dG-Na for bug-gnu-emacs@gnu.org; Tue, 24 Mar 2015 13:06:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaSHC-0008RS-Hv for bug-gnu-emacs@gnu.org; Tue, 24 Mar 2015 13:06:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaSHC-0008RM-F4 for bug-gnu-emacs@gnu.org; Tue, 24 Mar 2015 13:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YaSHC-0001lI-4i for bug-gnu-emacs@gnu.org; Tue, 24 Mar 2015 13:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Mar 2015 17:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20189 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20189-submit@debbugs.gnu.org id=B20189.14272167546758 (code B ref 20189); Tue, 24 Mar 2015 17:06:02 +0000 Original-Received: (at 20189) by debbugs.gnu.org; 24 Mar 2015 17:05:54 +0000 Original-Received: from localhost ([127.0.0.1]:35218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YaSH4-0001kw-3E for submit@debbugs.gnu.org; Tue, 24 Mar 2015 13:05:54 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:50140) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YaSH1-0001ki-BW for 20189@debbugs.gnu.org; Tue, 24 Mar 2015 13:05:52 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NLQ005007A5JS00@mtaout29.012.net.il> for 20189@debbugs.gnu.org; Tue, 24 Mar 2015 19:02:43 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLQ0042O7CJQ010@mtaout29.012.net.il>; Tue, 24 Mar 2015 19:02:43 +0200 (IST) In-reply-to: <87iodqbvoz.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100891 Archived-At: > From: Tassilo Horn > Date: Tue, 24 Mar 2015 10:18:04 +0100 > > With the widescreen displays that are common today, the default behavior > of `split-window-sensibly' is not always too sensible, and of course > what's sensible is determined by the user. So I'd suggest that some > alternative implementations are provided so that users can easily try > them out to find the one that suits them best. > > The problem with `split-window-sensibly' on a wide screen is that it > prefers vertical splits. The current emacs -Q behavior in a maximized > frame of size 269x82, the first split will be a vertical one. That's > pretty useless because then you have two windows with nearly 200 columns > of free space right of the buffer contents (assuming that usually most > buffer contents are at most 80 columns wide). 'split-window-sensibly' is documented to "split WINDOW in a way suitable for 'display-buffer'". Are you talking about the same use case, i.e. are you talking about some command that invoked 'display-buffer'? Or are you talking about some different use case? This is not clear from your description, since it lacks the context in which your needs are different. IMO, the rest of the discussion depends crucially upon the context, and in particular on the command that invoked 'display-buffer' (or maybe invoked 'split-window-sensibly' directly?). My understanding of the current logic is that 'display-buffer' is generally used for short-lived windows that are intended to be deleted a short time after the split. Long-lived splits are supposed to be caused by "C-x 2" and "C-x 3", where the user determines how to split anyway. If we are willing to produce long-lived splits automatically, then the 2 thresholds are IMO not enough for "sensible" behavior of any kind; what is missing is 2 more parameters that provide the desired (as opposed to minimal) height and width of a window. These parameters are implicitly present in your description, but you never explicitly name them. > It's exactly like `split-window-sensibly' except that the > horizontal/vertical clauses are reversed, i.e., it tries a horizontal > split before trying a vertical split. That version suits my needs a bit > better. > > However, it's still not exactly what I really want. The problem is that > after the first horizontal split I end up with 2 side-by-side windows > where each one is 132 columns wide. That's still much wider as needed > for most buffer contents but less than `split-width-threshold', so the > next splits will all be vertical ones so that I'll eventually end up > with four windows arranged in a 2x2 grid, each window having the size > 132x40. You never say what are your values of the 2 thresholds, so it is hard to reason about your description. > (1) That version would prefer horizontal splits as above. > > (2) I want either horizontal or vertical splitting but not both, i.e., > the layout should always be Nx1 or 1xN windows. > > (3) A window may get split horizontally not if it's wider/taller than > `split-width-threshold'/`split-height-threshold' but instead when > its width/height *after* the split followed by `balance-windows' > is larger than or equal to (/ split-{width,height}-threshold 2). > > (4) The single-window exception of `split-height-threshold' still > holds, so in frames with just one window a vertical split is > performed even though that window is actually too small according > to the rules above. Maybe I misunderstand, but doesn't (2) contradict (1)? And why is (1) a good idea anyway? Why not have a more optimal split, whereby (for example) the larger dimension is preferred? As for (3), such a criterion is IMO a good idea only if we actually balance the windows as part of the split. Otherwise, you will have adverse effects when the window to be split is very narrow, but some of its peers are wide. > When I use a frame of size 80x82 instead, I'd end up with 2 vertical > windows And this is good because?... FWIW, I'd prefer a 80x41 window to a 40x82 window, since 40 columns is way too few for editing a typical program or text buffer. Or do you have a lot of buffers with very short lines? It is also possible that in some cases the caller of split-window-sensibly could provide the requested dimensions in advance.