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: Thu, 26 Nov 2015 20:36:28 +0200 Message-ID: <83wpt4txoz.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> 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 1448563111 17653 80.91.229.3 (26 Nov 2015 18:38:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 18:38:31 +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 Thu Nov 26 19:38:16 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 1a21Qm-0001jx-70 for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Nov 2015 19:38:08 +0100 Original-Received: from localhost ([::1]:52768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a21Qo-0005Oz-3x for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Nov 2015 13:38:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a21Qk-0005OY-2K for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2015 13:38:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a21Qg-0001Kv-MU for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2015 13:38:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a21Qg-0001Kr-Hx for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2015 13:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a21Qg-0002fu-8O for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2015 13:38: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: Thu, 26 Nov 2015 18:38: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.144856302610156 (code B ref 22009); Thu, 26 Nov 2015 18:38:02 +0000 Original-Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 18:37:06 +0000 Original-Received: from localhost ([127.0.0.1]:54657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a21Pm-0002dj-2K for submit@debbugs.gnu.org; Thu, 26 Nov 2015 13:37:06 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:57306) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a21PR-0002cz-L5 for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 13:37:04 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NYF00M00Q9LSI00@mtaout26.012.net.il> for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 20:39:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYF00KB9QHY7N30@mtaout26.012.net.il>; Thu, 26 Nov 2015 20:39:34 +0200 (IST) In-reply-to: <56574A0F.101@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:109307 Archived-At: > Date: Thu, 26 Nov 2015 19:06:07 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > >> Note that ‘window-splittable-p’ is exclusively used by ‘display-buffer’ > >> and the probability is very high that the new window will not be used > >> for displaying the buffer of the original window. The new window will > >> very likely have its own margins and header line. > > > > Is it forbidden to call that function from any other Lisp? If so, > > disregard what I wrote. But if not, window-splittable-p should do a > > correct job no matter who calls it, do you agree? > > Presently ‘window-splittable-p’ is misnamed and I think that's the main > cause of the confusion. But its doc-string clearly names > ‘split-window-sensibly’ as the caller (which is misnamed as well but all > of these were written before ‘display-buffer’ was reorganized). In any > case both functions belong exclusively to ‘display-buffer’ and are not > related to C-x 3. > > > My text that you quoted here talks about the "normal" case, where the > > margins stay put upon splitting windows. I'm saying that in such a > > situation a decision made using the total width could be terribly > > wrong. > > But the "normal" case where this happens is C-x 3 and there the mode > that created the large margins should adapt. > > >> ‘window-min-width’ (and all related variables and functions) refer to > >> the total width of windows. Changing its semantics would constitute > >> quite some effort. > > > > If it's complicated, let's do that on master. But do it we must, IMO. > > Basically it would amount to ‘split-window-horizontally’ telling us that > it can't split the window. Which might not be the intention of the user > who expects the margins (whose sole purpose is to center the text in the > window) to shrink accordingly. > > But honestly I don't know which implications changing the semantics of > ‘window-min-width’ could have. I could imagine adding a new option say > ‘window-min-text-width’ and have the resizing routines respect this as > far as possible. Maybe we should step back and recall what problem are we trying to solve with the proposed patch, then. > >> > The modes that triggered this are special in that they adapt their > >> > margins to the split, but how would window-splittable-p know that? > >> > Perhaps such modes should override that function, or maybe we should > >> > provide a hook for them? > >> > >> This is not mode-triggered. > > > > In my text, "this" referred to this bug report. > > 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"?