From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.bugs Subject: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' Date: Tue, 01 Dec 2015 13:47:29 +0100 Message-ID: <87egf6z672.fsf@fastmail.fm> 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> 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 1448974104 11214 80.91.229.3 (1 Dec 2015 12:48:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Dec 2015 12:48:24 +0000 (UTC) Cc: 22009@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 01 13:48:11 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 1a3kLq-0000um-33 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Dec 2015 13:48:10 +0100 Original-Received: from localhost ([::1]:52244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3kLp-0000nB-JQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Dec 2015 07:48:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3kLl-0000n4-Rp for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 07:48:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3kLi-0007ol-JS for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 07:48:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3kLi-0007og-Gc for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 07:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a3kLi-0005fP-Co for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2015 07:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Joost Kremers Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2015 12:48: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.144897405921753 (code B ref 22009); Tue, 01 Dec 2015 12:48:02 +0000 Original-Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 12:47:39 +0000 Original-Received: from localhost ([127.0.0.1]:33824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3kLK-0005em-OR for submit@debbugs.gnu.org; Tue, 01 Dec 2015 07:47:39 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:44598) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3kLH-0005ed-KE for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 07:47:36 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 186E3206D3 for <22009@debbugs.gnu.org>; Tue, 1 Dec 2015 07:47:35 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 01 Dec 2015 07:47:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=h36re5rdbDOXJTyJ3PMTGEgAgIE=; b=q2nWfd vuHJGKzhYd5XtdThvP1El+SKhRwyzyVyLobHy9mcDwi1Ns7PX1pTcXMTFBU07oTE aFYaAClHyEoYbMPbsaKgenJ/UZDQ3Q4SjPjda2zPMVJuzd1XUbbIiU0K9wrd4oVI hy44NTdTB7U32GVBuqLuNO/+qY6mNiO8MiamA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=h36re5rdbDOXJTy J3PMTGEgAgIE=; b=b91Q81rnV3hwxtejZsGJyrh5W25kVHkCJCQ+gIFb+JzCh/7 zGjj4GPZcT9EdYm78skTZK+FZ/sGl5DNqm3+J0G7PPd38BVZQj06GSvi8O+jrBtA cS7/32LZwJaAcXkjpzzjZqdB0oP7lHoeWnl5QSy2ZWhpm/h8TY90QnSjOZAc= X-Sasl-enc: MD2C3+0uhWHqm9nNjAUJyyrjvFIG5RtDC3E61tf68xTP 1448974054 Original-Received: from IdeaPad.messagingengine.com (eruc065.goemobile.de [134.76.38.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A1986800EF; Tue, 1 Dec 2015 07:47:34 -0500 (EST) User-agent: mu4e 0.9.13; emacs 24.5.50.1 In-reply-to: <5659813D.1070509@gmx.at> 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:109496 Archived-At: On Sa, Nov 28 2015, martin rudalics wrote: > > 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 Yes, sorry about the confusion. I was initially confused myself (but not aware of it) when I posted my first message. It only became clear to me later that there were two issues. > Joost's use case with making a window on the right of an existing one to > show a buffer for `display-buffer'. Yes. > It's relevant because above you said that "display-buffer is not > relevant to the use case that Joost described, with those modes which > use margins". All I'm trying to do is to say that "only display-buffer > is relevant to the use case Joost cares about, with those modes which > use margins". But maybe it's better for Joost to tell. AFAICT that pretty much sums it up, at least as far as the patch that I sent is concerned. > > I should probably bail out of this discussion, because I feel I'm not > > contributing anything but my own confusion to it. > > Let me try to sum up the possible ways to get confused here. For a long > time we didn't have any problems or reports in this area because margins > were only used occasionally and in a very disciplined way. Then we had > ‘(n)linum-mode’ which started to use margins for displaying line > numbers. And now we have modes that use potentially large margins to > center text within a window. It's only the latter that introduce the > problems I list below. > > Another problem is that these modes conflict(ed) with ‘(n)linum-mode’ > when deciding on the size of the margins. This is part of other > threads, so I won't describe it here. Yes, it is necessary to keep these two issues apart. But. I think the only right way to solve the issue of *this* thread will involve solving the other issue as well. > The three major problems I see > are: > > (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). Yes. And it has two additional problems: it counts fringes, scroll bars and right dividers as well (as mentioned above). Plus it assumes that the *entire* margins are reducible if necessary, which is also not the case, since modes such as (n)linum-mode set a (left) margin and expect this margin to be preserved when the window is split horizontally. AFAIU all three problems amount to the same thing: currently, Emacs assumes that when a window's width is changed, the margins must be preserved. This assumption used to be correct, but with the introduction of `visual-line-mode', various hacks and modes have been written that use the margins to narrow the text area. When used this way, the margins do *not* have to be preserved when the window width changes. So essentially, since `visual-line-mode', the margins are being used in ways that have conflicting requirements when a window's width changes: some modes (such as (n)linum-mode) want the margins to be preserved, other modes (such as `visual-fill-column-mode' / `writeroom-mode') want the margins to be adjusted. The only way to resolve such conflicts is to keep track of what mode set the margins and whether they are adjustable or not. Then any part of Emacs that needs to decide whether or how a window's width can be changed can determine whether to just consider the text width, or the text width plus the margins. In other words, I don't think there's an easy fix that will really resolve the issue. From what I understand from Martin's comments, a proper fix is too involved to include in Emacs 25, so probably the best thing to do is to update the doc strings and close this bug. A proper solution can then be discussed on emacs-devel. -- Joost Kremers Life has its moments