From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii 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 17:32:39 +0300 Message-ID: <831t1rh14o.fsf@gnu.org> 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> <1471151490.3505042.694683657.3D32B261@webmail.messagingengine.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1471185261 9199 195.159.176.226 (14 Aug 2016 14:34:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Aug 2016 14:34:21 +0000 (UTC) Cc: 24193@debbugs.gnu.org To: Paul Rankin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 14 16:34:17 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 1bYwUS-00027U-T4 for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Aug 2016 16:34:17 +0200 Original-Received: from localhost ([::1]:32811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYwUP-0002Ca-PQ for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Aug 2016 10:34:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYwUJ-0002A7-1P for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 10:34:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYwUD-00053V-Sv for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 10:34:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYwUD-00053R-PO for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 10:34:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bYwUD-0000LH-Jw for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2016 10:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Aug 2016 14:34: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.14711851991261 (code B ref 24193); Sun, 14 Aug 2016 14:34:01 +0000 Original-Received: (at 24193) by debbugs.gnu.org; 14 Aug 2016 14:33:19 +0000 Original-Received: from localhost ([127.0.0.1]:57393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYwTW-0000KG-MN for submit@debbugs.gnu.org; Sun, 14 Aug 2016 10:33:19 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYwTU-0000K3-Q9 for 24193@debbugs.gnu.org; Sun, 14 Aug 2016 10:33:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYwTL-0004x9-MN for 24193@debbugs.gnu.org; Sun, 14 Aug 2016 10:33:11 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYwTL-0004x5-Jg; Sun, 14 Aug 2016 10:33:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1161 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bYwTC-0003Mo-0n; Sun, 14 Aug 2016 10:33:05 -0400 In-reply-to: <1471151490.3505042.694683657.3D32B261@webmail.messagingengine.com> (message from Paul Rankin on Sun, 14 Aug 2016 15:11:30 +1000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:122200 Archived-At: > From: Paul Rankin > Cc: rudalics@gmx.at, 24193@debbugs.gnu.org > Date: Sun, 14 Aug 2016 15:11:30 +1000 > > > 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. The function in question keeps the margins at their original size, so it cannot split the window when doing so leaves no screen space for buffer text. The only way to allow it to split such windows is by resizing the margins. Otherwise, what does "not make the assumption" mean in practice? We cannot rely on the application to resize the margins, because not every application does that (most don't). > 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. Not if the user does something that makes no sense. We have such "user errors" in Emacs all over the place. E.g., when the user tries to delete the only window of a frame. This case is no different, IMO. > 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. I already agreed that we should probably improve the error message, so let's not reiterate this particular aspect, as we are in agreement. IOW, the error message we issue now should no longer be an argument that what Emacs does in this case is wrong, let alone nonsensical. > 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. When we do so, we display hints about the truncation, and allow horizontal scrolling to display the truncated text. No such features are available for the stuff displayed on the margins, it just disappears without a trace. The example I provided, with linum-mode, is a relevant case in point: the line numbers will appear incorrect and/or corrupted. > 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... It is worse because the effect is a corrupted display with no hint to the user. > > 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. The error message, when we fix it, will explain 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. The function in question doesn't change the margins, so it cannot do its job when no screen estate is left for the text area. IOW, there's no assumptions here, only facts. > > 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. No, it isn't, because we do that in other cases. > 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. I'm not sure we want to change window-min-size. That function is used for purposes that have nothing to do with splitting the window. E.g., we also use its value when deciding whether a window can be resized, when fitting window to buffer, etc. The lowest level function for splitting windows is split-window, so the change should IMO be either in split-window-right or in split-window. Martin, WDYT? > 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? See above. Also, this proposal is incomplete, because it doesn't tell what should window-splitting functions do when the margins are too wide for one or both of the two windows after the split. You explicitly say that you don't suggest that margins be resized when such windows are split, so it is not clear what should be done in those cases. Thanks.