From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.devel Subject: Re: Window splitting issues with margins Date: Thu, 19 Nov 2015 14:46:58 +0100 Message-ID: <87si4214q5.fsf@fastmail.fm> References: <874mgrwerb.fsf@fastmail.fm> <5644A2AC.3080703@gmx.at> <871tbux3vb.fsf@fastmail.fm> <564599A6.6060306@gmx.at> <838u62guhm.fsf@gnu.org> <87mvugs4la.fsf@fastmail.fm> <836112c554.fsf@gnu.org> <87mvudlw6g.fsf@fastmail.fm> <564A26ED.6000208@gmx.at> <564AE6ED.5080002@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 1447940873 30382 80.91.229.3 (19 Nov 2015 13:47:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 13:47:53 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 19 14:47:38 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZzPYS-0006Ya-Ht for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 14:47:17 +0100 Original-Received: from localhost ([::1]:41763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzPYR-0006Hn-LU for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 08:47:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzPYL-0006AO-5y for emacs-devel@gnu.org; Thu, 19 Nov 2015 08:47:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzPYI-0007oK-5v for emacs-devel@gnu.org; Thu, 19 Nov 2015 08:47:09 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:57217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzPYH-0007nM-Sa for emacs-devel@gnu.org; Thu, 19 Nov 2015 08:47:06 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2499320974 for ; Thu, 19 Nov 2015 08:47:04 -0500 (EST) Original-Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 19 Nov 2015 08:47:04 -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=AWByts2QjE6eMsZdTCySOPG73Uw=; b=nSXKvZ /fHS9+EqaMTFPZJs7w9/7UGh+unrJ/SUonuYHekK9YfbtpvqcECsk82rI+sLvxnC P5cKqeumLKXaeMP4bmbml1reS8izxf3vCxrc+irztXpjUn2Ys0JbKeZ7MivDJu1t Ni7EAYM9MeqE7zqpkiGEOfGES3oKwRob5aTzI= 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=AWByts2QjE6eMsZ dTCySOPG73Uw=; b=EgHKr5MaIz6CQmWB16fvJFT/WciAsICwvG7fuw/8I6IXzg3 eoDLCMhexNmkXtWiN7f1jBecAiZ7QlmSdUgmdEkTSgFkf2JVDB2gVPWzl9XRYtcn W/44MYbxTcjxSkbvst9tYhciKsVlzWr0Cw3IFnFu4YZ+iYB64tKPjcNWZRa8= X-Sasl-enc: Yp4eXhuFav5ti3q0y0+fUm6yVAlUCUic1yoL0RBluMwv 1447940823 Original-Received: from IdeaPad.messagingengine.com (eruc064.goemobile.de [134.76.38.64]) by mail.messagingengine.com (Postfix) with ESMTPA id 3AA4EC016F4; Thu, 19 Nov 2015 08:47:03 -0500 (EST) User-agent: mu4e 0.9.13; emacs 24.5.50.1 In-reply-to: <564AE6ED.5080002@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.29 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194787 Archived-At: On Di, Nov 17 2015, martin rudalics wrote: > > Actually, I care about window-splittable-p, not about > > split-window. split-window is not a problem, because after it's done > > its work, window-configuration-change-hook is run, where > > writeroom-mode can (and in fact already does) adjust the window > > margins. > > If it's arranged to run after the function ‘linum-mode’ put on > ‘window-configuration-change-hook’. Yes, which is why `writeroom-mode' appends its update function to `window-configuration-change-hook'. However, even though `linum-mode' prepends its own update function `linum-update-current', it still usurps the left margin, probably because `linum-update-current' is also added to `post-command-hook'. For clarity, the value of `window-configuration-change-hook' when both writeroom-mode and linum-mode are enabled in a buffer is: ``` (linum-update-current t visual-fill-column--adjust-window) ``` (Note that writeroom-mode doesn't actually modify the margins itself. It uses `visual-fill-column-mode' for that). `nlinum-mode' seems to behave better, BTW. It doesn't set the margins' width after each change or after each command, it seems to do that in just two cases: when the window configuration is changed, and if it needs more room for the line numbers (e.g., when line number 100 is reached). The former is handled by appending rather than prepending `visual-fill-column--adjust-window' to `window-configuration-change-hook', so is not a problem. The latter unfortunately still destroys the margin set by `writeroom-mode', but things are restored again by any operation that calls `window-configuration-change-hook'. > > The problem with window-splittable-p is that it decides whether a > > window can be split horizontally *before* writeroom-mode has a chance > > to adjust the margins. Since in the cases I'm talking about, most of > > the window width is taken up by the margins, window-splittable-p > > thinks that the window is rather narrow (80 characters, the width of > > the text area), while in fact it is quite wide (over 200 chars) and > > could be split horizontally (because most of those 200 chars are not > > used for anything except keeping the text width small). > > Aha. So you want to use ‘window-total-width’ instead of > ‘window-text-width’ here. Sounds reasonable. Yes. Sorry, I could have been clearer about that earlier. The modified `window-splittable-p' that I have in my init file makes exactly this single change. > ‘window-splittable-p’ uses ‘window-width’ and ‘window-height’ just > because these were there at the time the function was written. If no > one objects let's make it use total sizes in both directions. I'd be all for it. > OK. But you rely on the fact that ‘writeroom-mode’ is able to run its > hook functions after ‘linum-mode’. This dependency is not very stable. Nope. > > (2) When the margins are used to narrow the text width, > > window-splittable-p should take that into consideration when deciding > > if a window can be split horizontally. Right now, it doesn't. > > > > I think (2) is a relatively minor issue. The worst thing that happens > > is that a window is split vertically that could have been split > > horizontally, e.g., when a help window is popped up. Still, I think it > > would be fairly easy to fix once issue (1) is taken care of. > > But using ‘window-total-width’ in ‘window-splittable-p’ would fix (2). > Correct? Yes. > > (1) is a more serious issue, and one thing (though not the only thing) > > that needs to be recognised in order to find a way to deal with it is > > that the margins can be used for two fundamentally different types of > > purposes. On the one hand, they can be used to display some useful > > information about the buffer being shown in the window. On the other > > hand, they can be used to adjust the width of the text area. The > > crucial difference is that for the former purpose, the margins should > > not be reduced when the window width changes, while for the latter > > purpose, they can be adjusted freely. (Put differently, in the former > > case, the margins trump the text width, while in the latter, the text > > width trumps the margins). > > The only thing we can do is to say in the documentation that when two > packages contend for the same margin, the one that tries to do that > later in the redisplay cycle will succeed. Perhaps it could also be added that in order to reduce (though not eliminate) the risk of interoperability problems, packages (1) should examine the width of the margins before changing them (e.g., in `window-configuration-change-hook'); (2) should not set the margins to a width lower than the existing width; and (3) should restore the original width when they are disabled (or rather, restore the width that existed before the last time they changed the margins). This policy won't be failure proof, but it should minimise annoyances for users and should make it easier to live with such annoyances when they do occur (by doing something that causes `window-configuration-change-hook' to be run, e.g., switching to another buffer and back, splitting and unsplitting the window). -- Joost Kremers Life has its moments