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: Wed, 25 Mar 2015 19:25:59 +0200 Message-ID: <83egodouoo.fsf@gnu.org> References: <87iodqbvoz.fsf@gnu.org> <83384uqqao.fsf@gnu.org> <871tkd36jx.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427304450 3450 80.91.229.3 (25 Mar 2015 17:27:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Mar 2015 17:27:30 +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 Wed Mar 25 18:27:19 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 1Yap5D-00009s-SH for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Mar 2015 18:27:12 +0100 Original-Received: from localhost ([::1]:40415 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yap5D-0001Tg-0D for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Mar 2015 13:27:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yap58-0001Tb-O5 for bug-gnu-emacs@gnu.org; Wed, 25 Mar 2015 13:27:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yap54-0007Ep-6t for bug-gnu-emacs@gnu.org; Wed, 25 Mar 2015 13:27:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yap54-0007Ee-2u for bug-gnu-emacs@gnu.org; Wed, 25 Mar 2015 13:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yap53-0004Sl-Mq for bug-gnu-emacs@gnu.org; Wed, 25 Mar 2015 13:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Mar 2015 17:27:01 +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.142730437817096 (code B ref 20189); Wed, 25 Mar 2015 17:27:01 +0000 Original-Received: (at 20189) by debbugs.gnu.org; 25 Mar 2015 17:26:18 +0000 Original-Received: from localhost ([127.0.0.1]:36576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yap4L-0004Rg-MP for submit@debbugs.gnu.org; Wed, 25 Mar 2015 13:26:18 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:44635) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yap4I-0004RO-VX for 20189@debbugs.gnu.org; Wed, 25 Mar 2015 13:26:16 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NLS008002RTDT00@mtaout25.012.net.il> for 20189@debbugs.gnu.org; Wed, 25 Mar 2015 19:21:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLS0025S2VCAD60@mtaout25.012.net.il>; Wed, 25 Mar 2015 19:21:12 +0200 (IST) In-reply-to: <871tkd36jx.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:100926 Archived-At: > From: Tassilo Horn > Cc: 20189@debbugs.gnu.org > Date: Wed, 25 Mar 2015 08:00:34 +0100 > > > '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? > > Yes, I'm talking about display-buffer. This is a test case: > > --8<---------------cut here---------------start------------->8--- > (defun test-display-buffer () > (interactive) > (display-buffer (get-buffer-create "ONE")) > (display-buffer (get-buffer-create "TWO"))) > --8<---------------cut here---------------end--------------->8--- > > If your screen is as large that your emacs frame/window is taller than > `split-height-threshold' (80 lines), then the first split will be a > vertical one. E.g., do emacs -Q, eval the above function in *scratch*, > and then M-x it. You end up with 3 windows: one wide window on top > showing *scratch*, the lower half contains two side-by-side windows. I don't see how we can judge "sensibility" of what display-buffer does without knowing which command(s) invoked it. Users don't invoke display-buffer directly, and the commands that do differ widely in the amount and dimensions of text they display and subsequent use of the displayed stuff. As a simple example, a command that calls display-buffer could prepare text that is best shown in a 100x10 window (think about some columnar display), in which case it doesn't make sense to prefer 80-column wide side-by-side windows that you seem to prefer. > That's not too sensible when one assumes that most buffers are at most > 80 columns wide but have many lines. If the first split was a > horizontal split, you'd have more buffer contents on your screen. As you see from your own description, the "sensibility" depends quite a lot on the preferred dimensions and the nature of the text to be displayed. I'm not at all sure we can find a "one size fits all" strategy, at least not without examining the text itself, something split-window-sensibly doesn't do, AFAIK. > > This is not clear from your description, since it lacks the context in > > which your needs are different. > > The context is having a big enough screen where both a vertical and a > horizontal split would be possible initially. No, I meant the commands that invoked display-buffer -- they are the most important context for "sensibility" of the split. > > 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. > > Yeah, exactly. I personally defined them to be > > (/ split-{width,height}-threshold 2) > > although I think the preferred height is usually "as high as possible" > or "exactly as high to fit the buffer contents". Once again, I think this depends on the text to be displayed. If we want to have a split-window function that does not consult the text to be displayed, the only way to go is IMO to parameterize the problem space, and make the function accept these parameters and DTRT for each combination. > >> (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)? > > No. (1) is meant for the initial split case, i.e., when there's just > one window. If that's splittable both vertically and horizontally, I > prefer a horizontal split. That's a far cry from what you wrote in (1). > > And why is (1) a good idea anyway? Why not have a more optimal split, > > whereby (for example) the larger dimension is preferred? > > IMO, a vertial split which produces windows which are much larger than > 80 columns is useless to me because usually buffer contents are at most > 80 columns wide so you have tons of empty space next to the contents. If the horizontal dimension of the initial widow to be split is larger than the vertical one, then the rule I propose will always do what you want for the first couple of splits. After that, I see no reason to prefer splitting, say, a 120x80 window into 2 60x80 windows instead of into 2 120x40 windows. > Ok, there might be a situation where my single window contains a buffer > with very wide contents. Let's say in that case, the optimal window > split function would determine that a vertical split is better. With my > usage habits, I'd still say its wrong because chances are almost certain > that I'll switch buffers sooner or later, and the buffer being switched > to is most probably at most 80 columns wide again. You do see how this line of reasoning is deeply specific to your habits, don't you? Which means there cannot be on strategy that fits all of us. > There might be some "dynamic" window adaption manager which computes an > optimal window configuration after every `set-window-buffer'. But I'm > not sure if that is feasible and provides a good user experience. We need to define the strategy for such an optimization first, then we can reason about whether users will like it, and how to customize it to user needs. > > 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. > > Yes, in my last mail I've hacked a split function which does exactly > that. But actually balancing windows would be a bad idea for some users of display-buffer, at least in my eyes. A typical example is the *Compilation* buffer and its ilk: I generally want them to keep their small size, not to steal screen estate from my editing windows. Similarly with *Help* etc. > >> When I use a frame of size 80x82 instead, I'd end up with 2 vertical > >> windows > > > > And this is good because?... > > Exactly because of the reason you state below. The frame/window isn't > wide enough to have 2 side-by-side windows with at least 80 columns > each, so that's the case where I favor vertical over horizontal > splitting. That's because you think about displaying some program text there, or similar. But what if the text to be displayed there is much more narrow, or even adapts itself dynamically to the window dimensions, like the *Completions* buffer?