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: Fri, 27 Nov 2015 22:51:45 +0200 Message-ID: <83oaefqi72.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> 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 1448657606 5831 80.91.229.3 (27 Nov 2015 20:53:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 20:53:26 +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 Fri Nov 27 21:53:12 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 1a2Q0x-0007ZV-LJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Nov 2015 21:53:07 +0100 Original-Received: from localhost ([::1]:58473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Q10-0007d8-3o for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Nov 2015 15:53:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Q0v-0007d2-Un for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2015 15:53:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2Q0s-0002mE-FX for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2015 15:53:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Q0s-0002m9-CE for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2015 15:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a2Q0s-0004kE-13 for bug-gnu-emacs@gnu.org; Fri, 27 Nov 2015 15:53: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: Fri, 27 Nov 2015 20:53:01 +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.144865752618066 (code B ref 22009); Fri, 27 Nov 2015 20:53:01 +0000 Original-Received: (at 22009) by debbugs.gnu.org; 27 Nov 2015 20:52:06 +0000 Original-Received: from localhost ([127.0.0.1]:56495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2Pzx-0004hI-9v for submit@debbugs.gnu.org; Fri, 27 Nov 2015 15:52:05 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:42056) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2Pzs-0004gd-Ld for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 15:52:02 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NYH00A00QA7FO00@mtaout29.012.net.il> for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 22:51:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYH0052IR9SNR70@mtaout29.012.net.il>; Fri, 27 Nov 2015 22:51:29 +0200 (IST) In-reply-to: <565813FB.6040604@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:109343 Archived-At: > Date: Fri, 27 Nov 2015 09:27:39 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > > Maybe we should step back and recall what problem are we trying to > > solve with the proposed patch, then. > > The current code is inherently wrong because it treats height and width > differently. And it's not about the margins alone but also about > fringes, scroll bars and dividers. But this is a very old inconsistency > and I never worried to much about it. Joost uncovered it. 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. So why should we do anything about window-splittable-p if it only affects functions that are not relevant to Joost's use case? Hence my question: if we aren't fixing Joost's use case, and display-buffer is not relevant to splitting windows with large margins, what problem we are trying to solve with that patch? 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 you mean that a mode introducing large margins should override > >> ‘split-window-sensibly’ then this is not TRT. ‘split-window-sensibly’ > >> is user territory and ‘window-splittable-p’ too. > > > > 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? > It would be more correct to rename > > ‘split-window-preferred-function’ -> ‘display-buffer-split-window-preferred-function’ > > ‘split-window-sensibly’ -> ‘display-buffer-split-window-sensibly’ > > ‘window-splittable-p’ -> ‘display-buffer-window-splittable-p’ > > in order to avoid the misunderstandings we have here. And how is this renaming relevant to the patch that is being discussed? I should probably bail out of this discussion, because I feel I'm not contributing anything but my own confusion to it.