From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Rankin Newsgroups: gmane.emacs.bugs Subject: bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text Date: Sun, 14 Aug 2016 15:11:30 +1000 Message-ID: <1471151490.3505042.694683657.3D32B261@webmail.messagingengine.com> References: <1470734067.1046352.690034953.5B0A54FE@webmail.messagingengine.com> <57A9A714.4010600@gmx.at> <1470736919.1056423.690073473.51DB916F@webmail.messagingengine.com> <57A9AD24.6090303@gmx.at> <1470739033.1062589.690104169.1A130EC9@webmail.messagingengine.com> <83ziomgfcd.fsf@gnu.org> <1470755912.754355.690353977.4F305064@webmail.messagingengine.com> <83r39ygcr5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1471151542 2156 195.159.176.226 (14 Aug 2016 05:12:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Aug 2016 05:12:22 +0000 (UTC) Cc: 24193@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 14 07:12:18 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYnic-0000Lb-Au for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Aug 2016 07:12:18 +0200 Original-Received: from localhost ([::1]:59611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYniZ-0008LJ-FP for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Aug 2016 01:12:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYniS-0008L0-Fi for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 01:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYniO-0007RP-3l for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 01:12:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYniL-0007RE-Qc for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 01:12:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bYniL-0000Jb-IY for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 01:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Rankin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Aug 2016 05:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24193 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24193-submit@debbugs.gnu.org id=B24193.14711514941173 (code B ref 24193); Sun, 14 Aug 2016 05:12:01 +0000 Original-Received: (at 24193) by debbugs.gnu.org; 14 Aug 2016 05:11:34 +0000 Original-Received: from localhost ([127.0.0.1]:56721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYnhu-0000Ir-4K for submit@debbugs.gnu.org; Sun, 14 Aug 2016 01:11:34 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:35196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYnhr-0000Ii-DJ for 24193@debbugs.gnu.org; Sun, 14 Aug 2016 01:11:32 -0400 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1B99320215; Sun, 14 Aug 2016 01:11:31 -0400 (EDT) Original-Received: from web1 ([10.202.2.211]) by compute7.internal (MEProxy); Sun, 14 Aug 2016 01:11:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=paulwrankin.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=mesmtp; bh=lutGCyAbZ8H9ncpq25I0Y0feFxw =; b=S8q+xsnVE5LAfsYBE/3rEAhr2aQUqJLGCBTxfR3K6EZK5rq54RxTXylVsTZ gpH1A7JdBeIVbD0sk3pIfKIpHuqptthgEVLc2fxyv66iTVqGWO9WWCMwM7iwIqXb ey0MKGOixRJX/l6c2+xEc5J8Ll1F6jGegO776IJUGumfsPcs= 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=lutGCyAbZ8H9ncp q25I0Y0feFxw=; b=FRg7DfzYLeWZDR0a3xSPbV3PVuzGJwh55WQk0zVpzUsnslc QTMFpwmcbpR3xxU4Ym1/yJ79kwncPiYNh/qunnsOmUV+0PnEbbx4LxlvDpjXmwcw vAAz9kOtrOI29hTWtW4alFnpxGXQHkYDtTPfICef9NbmgX0wUjhvqSw3Kobg= Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id CE8BC6A5F7; Sun, 14 Aug 2016 01:11:30 -0400 (EDT) X-Sasl-Enc: lz8yhmJ4guC9SPkGBHmxt2W6U8khfT+K81gXqGOHdBxb 1471151490 X-Mailer: MessagingEngine.com Webmail Interface - ajax-71d1d584 In-Reply-To: <83r39ygcr5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:122193 Archived-At: Eli Zaretskii on Tue, 09 Aug 2016 18:53 +0300: > Decreasing the width of the margins when splitting a window causes > worse problems: if the smaller margin cannot display the stuff (text, > image, etc.) that the application wants to display there, that stuff > will be truncated, or not shown at all. E.g., the line numbers shown > by linum-mode will become truncated if the margins are made narrower > than what linum-mode needs. Worse, linum-mode recalculates the margin > width from time to time, and so it will try to enlarge the margin, > making the text area smaller than it can possibly be. These are > catastrophic failures that we cannot impose on Lisp applications. I'm not suggesting that Emacs resize the margins, just that Emacs ought not make the assumption that wide margins mean that splitting the window is unsafe. I think your ordering of priorities is a bit off. The top priority here is that the user needs to be able to press C-x 3 and have the window split in this use case. e.g. If the user has a window 204 columns wide with margins each set at 62 columns (with a remaining text body width of 80 columns), attempts to split that window with C-x 3 and receives a "Window X too small for splitting" error, given that the window is quite wide and Emacs is saying it's too small, the user's justifiable assumption is that Emacs is broken. Also, buffer contents is truncated all the time... Whenever a line exceeds the window width and truncate lines is t then we get a $ with truncated text. I don't get your concern here, and especially why truncating content is worse than breaking core Emacs functionality (C-x 3) with these use cases... > From my POV, the 24.x behavior was broken, see above. We changed that > to avoid those problems. An application that sets a margin of a > certain width has every right to expect Emacs not to change that. Your POV is valid as someone focused on the code, but here it's a different POV to that of a user, who sees a large window and expects splitting it to work, because it did in 24.x, so why not now. Really, Emacs is making a false assumption here, which is that when I split the window I am not also somehow controlling the margin width (in this case, with one of a variety of minor modes). So this attempt to perform some user mind-reading is the root of the design failure. When Emacs doesn't know, Emacs ought to adopt the position "idk?" and just do what it's told. When you assume you make an ass of u & Emacs. > If the error message is unclear, we can and should improve it. But I > don't think this is the main issue at hand here. Yeah it seems the author wants to include something like an error code, which here is misleading because it resembles (list 2). > Sorry, rolling this back is out of the question. The current behavior > was discussed at length, and was introduced to fix problems that I > think are much worse. So too should failing in a common use-case be out of the question. It would appear that these discussions adopted a very ungracious view of the mentioned prose-writing packages, that is, rather than find a solution for both cases, that these packages should just fail? > Emacs cannot possibly know that the application which set the margins > can cope with decreasing the margins. Only the application (or the > user) know that. > > Anyway, I think these particular modes were also discussed in the > context of this change in behavior. I think one way of dealing with > this issue in the modes you mention is to bind "C-x 3" to a > specialized command that reduces the margins before it calls window- > split. An application can do this because it knows its features and > limitations; Emacs core cannot. I think rebinding C-x 3 is a messy solution. The problem isn't really with split-window-right, it's with window-min-size. For example, one use-case I've come up against a lot is when working with a text file under git version control with olivetti on (which automatically sets the margins quite wide) in a single window. Activating magit would usually split the window horizontally, but because of the wide margins, the window will split vertically. This behaviour is not a big deal, but the user expectation when looking at a wide window with wide margins containing lots of empty space is that the window ought to split horizontally. Other results look a bit off. An idea I just thought of, so feel free to poke holes in it, is to introduce a local variable, something like window-margins-resizable, which defaults to nil, but could also be t left or right. This alleviates the problem of Emacs needing to read the user's mind when it comes to whether the margins really are too big to split the window or being controlled otherwise. Thoughts?