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#22009: PATCH: Use `window-total-width' in `window-splittable-p' Date: Sat, 28 Nov 2015 16:49:56 +0200 Message-ID: <83io4mp4a3.fsf@gnu.org> References: <87io4qgrcg.fsf@fastmail.fm> <5655F45F.4050406@gmx.at> <83vb8qvttj.fsf@gnu.org> <5655FAA2.80406@gmx.at> <83k2p5x54k.fsf@gnu.org> <5656C171.9050506@gmx.at> <83r3jcvk4l.fsf@gnu.org> <56573A22.6070309@gmx.at> <8337vsvfj6.fsf@gnu.org> <56574A0F.101@gmx.at> <83wpt4txoz.fsf@gnu.org> <565813FB.6040604@gmx.at> <83oaefqi72.fsf@gnu.org> <5659813D.1070509@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1448722283 20621 80.91.229.3 (28 Nov 2015 14:51:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Nov 2015 14:51:23 +0000 (UTC) Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 28 15:51:08 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 1a2gqB-0004AK-3g for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Nov 2015 15:51:07 +0100 Original-Received: from localhost ([::1]:60985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2gqE-0006oT-G9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Nov 2015 09:51:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2gqA-0006oD-51 for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2015 09:51:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2gq6-0006H7-Ss for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2015 09:51:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2gq6-0006H2-P9 for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2015 09:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a2gq6-0007w4-CA for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2015 09:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Nov 2015 14:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22009 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22009-submit@debbugs.gnu.org id=B22009.144872223330468 (code B ref 22009); Sat, 28 Nov 2015 14:51:02 +0000 Original-Received: (at 22009) by debbugs.gnu.org; 28 Nov 2015 14:50:33 +0000 Original-Received: from localhost ([127.0.0.1]:57657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2gpc-0007vL-58 for submit@debbugs.gnu.org; Sat, 28 Nov 2015 09:50:32 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:53735) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2gpF-0007ur-9D for 22009@debbugs.gnu.org; Sat, 28 Nov 2015 09:50:28 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NYJ002004HN4G00@a-mtaout20.012.net.il> for 22009@debbugs.gnu.org; Sat, 28 Nov 2015 16:50:06 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYJ001JF57IOJ90@a-mtaout20.012.net.il>; Sat, 28 Nov 2015 16:50:06 +0200 (IST) In-reply-to: <5659813D.1070509@gmx.at> 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: 208.118.235.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:109366 Archived-At: > Date: Sat, 28 Nov 2015 11:26:05 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > > Yes, but this doesn't seem to answer my question. I already agreed > > that there's inconsistency, the question is how to fix it. I > > suggested one way of reasoning, but you rejected it saying that the > > code in question only affects a function that is only used by > > display-buffer. But display-buffer is not relevant to the use case > > that Joost described, with those modes which use margins. > > Indeed. Joost's description of his fix is too general, it alludes to > solving problems with C-x 3. I initially misunderstood too as you can > derive from the following dialogue in a different thread. I said that > > > As I tried to explain before: ‘window-splittable-p’ is hardly the > > function we care about here. We care about ‘split-window’ itself. > > and Joost answered > > > Actually, I care about window-splittable-p, not about > > split-window. split-window is not a problem, because after it's done > > its work, window-configuration-change-hook is run, where > > writeroom-mode can (and in fact already does) adjust the window > > margins. > > So your question > > > So why > > should we do anything about window-splittable-p if it only affects > > functions that are not relevant to Joost's use case? > > should be answered now. Correct? Yes, thanks. But that still doesn't suggest how to fix window-splittable-p, unless we care _only_ for Joost's use case. And I don't think we can declare that only such use cases matter, as window-splittable-p is too general-purpose for that. > > More importantly, if there isn't a clear-cut use case that will allow > > us to decide which is the correct behavior, how can we decide whether > > to make this change on master or on the release branch? And why did > > you feel it was so important to fix it on the branch? What's the > > urgency? > > If the fix is wrong it will be wrong for master too. And if I don't fix > the code for the release branch but do care about the correctness of our > docs, I have to rewrite doc-strings and Elisp reference in order to > describe the inconsistency between vertical and horizontal splitting for > the release branch. This is a bug I could ignore for some time simply > by not looking at the code more deeply. Once I look at the code and see > what it does, I have to react either by correcting the code or by > changing the documentation. Anything else would be irresponsible. We agree that the code should be fixed. We just disagree about (or don't know) _how_ to fix it. > >> > Didn't you just tell they are called by display-buffer? How's that > >> > "user territory"? > >> > >> The option ‘split-window-preferred-function’ is by default set to > >> ‘split-window-sensibly’. It's exclusively in the hand of the user to > >> change that. A mode that wants to change whether and how > >> ‘display-buffer’ is supposed to split a window should specify its own > >> buffer display action in the call to ‘display-buffer’. > > > > OK, and I'm still asking: how is all that related to > > window-splittable-p? When we talk about that function, what is the > > relevance of the user's ability to replace it to the discussion? > > If it is not related then I missed again what you were asking. I tried > to guess twice but am apparently too silly to grok it. Forget it, it isn't related to the issue, so there's no need to explore this further. > (1) When a mode uses margins to center text and you want to split the > corresponding window via C-x 3, ‘split-window-right’ may refuse to > split the window because the decision whether to split the window is > based on the assumption that the margin widths in the original > window shall be preserved. > > (2) When a mode uses margins to center text and you want to resize the > corresponding window horizontally via ‘mouse-drag-vertical-line’, > the latter may refuse to do that because the decision whether to > shrink the window is based on the assumption that its margin widths > shall be preserved. > > (3) When a mode uses margins to center text and you want to split the > corresponding window for displaying a buffer via ‘display-buffer’, > ‘split-window-sensibly’ may refuse to split the window because the > decision whether to split the window is based on the assumption that > the window to be split is only as wide as its text area. Since this > wide can be comparably small in a window that uses margins to center > text, the attempt to display a buffer on the right may often fail > unexpectedly. > > Joost's fix is exclusively for problem (3). Agreed. And I don't think we can fix this only for that use case. We should try to look for a more general solution.