From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window splitting issues with margins Date: Thu, 12 Nov 2015 15:31:08 +0100 Message-ID: <5644A2AC.3080703@gmx.at> References: <874mgrwerb.fsf@fastmail.fm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447338698 23892 80.91.229.3 (12 Nov 2015 14:31:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 14:31:38 +0000 (UTC) To: Joost Kremers , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 15:31:31 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 1ZwsuQ-0006bP-67 for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 15:31:30 +0100 Original-Received: from localhost ([::1]:46994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwsuP-0000ZB-IP for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 09:31:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwsuK-0000Yx-Lo for emacs-devel@gnu.org; Thu, 12 Nov 2015 09:31:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwsuE-0007LH-MT for emacs-devel@gnu.org; Thu, 12 Nov 2015 09:31:24 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:53774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwsuE-0007LD-CE for emacs-devel@gnu.org; Thu, 12 Nov 2015 09:31:18 -0500 Original-Received: from [192.168.1.101] ([213.162.68.27]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZwYd-1ZhI8D3WBz-00LnEZ; Thu, 12 Nov 2015 15:31:14 +0100 In-Reply-To: <874mgrwerb.fsf@fastmail.fm> X-Provags-ID: V03:K0:tvl5i6ng0KENrIF0w9KZODemr9LbavqXfjf57frcc7IKWjEftZo T7s6FMrl/VjaBeJ8h5ofDCSRa4XH0qpyzWooc+4L1467mlWkAM1UdIzZbeRs+q57ZxQOGPU oHIsXH1CzFMjvktby+yevz3uiH+Rx3CA2OM8tdaYmqpnrTh8K0EpfS+mGApgkR8zRnFueom YK956sfYdXO2JalwiJnxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:/MO4IsMano4=:cFZKdFfoe95IO01aTElQ+S QZ97UkFe9CbkPCrYiOs8d9+Fp6aX4NQI8SxDTFRybEgo2GCK53NMnnwwwusZCojTa5vf9nsN5 LWSeSlR7Fe7tgp7U0DUZQa74YJ8yTkpUpA/8d5/JgWmoQBmuBRDI+8KawTdHMGRKPuyziBVu0 L/Goi/P9huysGWLlgprVL4mEuSJcn8g+BGVXegrpkJVXY81AbKfDuuQ/vsexdE37AYUTBu82t xufEWbm+78y2LMV4yXpDp9AvKiG8GoxwS1oALv9bUuPgi/9kzUo7tT7iLJVmwXQQS9TVTsOTo Utferxes47bNKXpfwr9rHUnQIA+qhT1K3vUsEIEGdUjR6e+gj6ViewZs9bYxWIraAEjjEXD9D JHl7YmEWfXZuoKcCUwl/zeVfcxQva8R97YHbdLDgDaVCOMN/gPqPb6RYX38bgumqwBHGi5UaU hqA6MKeSkeQv091iF7ODWGYyL1Yz4NW2GxCGoVEKVjTx3O9uOCnAcBtVMIXVj6BsJgt3cPPja Zh4Y9VBYIBZs+vSvRIHT6sSx6pLukFaE8mY9JCEWmBWwZTdisbCb89jPGRM+Vkz8uAVE37i/A v4QrflLL5ZYTWg+dREEMlJBhyUVnDOdeFMKCAF7i7tCoxLYCQzL5X+3kbhUtB/+rJaRuSyvzf 7bwyrok0cmpzXRoYIdFhHPaIuUeqPjadX+rOEmfDckK4HECD0Q48Z1LJcGdydJCaXrS36Wh/K 1ugSeUjiqgcqNt3nEE8KsH8F2DlTcYNiiIph9n2W2qy7N862auuVeJuC+3+u7+ijmlHKQQR3 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.20 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:194227 Archived-At: > I maintain a package called visual-fill-column[1] that mimicks the > effect of `fill-column' in buffers with `visual-line-mode' turned on b= y > widening the window margins. As such, I ran into an issue with window > splitting that I believe Emacs should handle better. > > If I split a window horizontally[2] that has a wide margin, e.g., with= > `split-window-right', the width of the text area is reduced to a minim= um > of 2 columns before the margins are reduced. At least that is my > impression from the following test: > > - emacs -Q > - make sure you have a wide frame > - load any text file (to better see the effect) > - M-x eval (set-window-margins (selected-window) 0 150) > - C-x 3 (split-window-right) > > Depending on the width of the frame and the size of the right margin, > the text is now reduced to a very small width, while the margin is muc= h > wider. > > I think it would make more sense to reduce the margin before reducing > the text width. The margins you set above become a window property. If after C-x 3 you do C-x 1 your are left with the reduced margins which might not be what you want. Deciding when and how to auto-adjust margins is not trivial. I would do that in =E2=80=98visual-fill-column=E2=80=99. > A related problem is the fact that `window-splittable-p' only takes th= e > width of the text area into account when deciding if a window can be > split horizontally. This often leads to the situation where a window i= s > split vertically, although there appears to be enough room to split it= > horizontally (said room being taken up by the margin). I agree with this observation. =E2=80=98window-splittable-p=E2=80=99 is = asymmetric: When it checks the width, it uses the text area while for the height it uses the total area (inlcuding mode and header lines, scrollbar, divider =2E..). If you want to change this, please provide a patch. I certainly= won't object it but am afraid that some people eventually will complain because one of their packages then doesn't work like it used to over the past decades ... BTW: Bug#5944 is about a related issue. I never got around to resolve it for a similar reason. > Also, there is no built-in function that returns the width of the wind= ow > without the fringes, scroll bar and right divider, but *with* the > margins. But it's not overly hard to write such a function ;-) > There is `window-text-width' and `window-body-width' (which, > despite their names, both only look at the text width; If your read the Elisp manual (section 27.3 Window Sizes) you will notice that "text area" and "window body" denote one and the same thing. > though the latter > has a PIXELWISE argument that the former lacks The former will have one in Emacs 25.1. But you should always use =E2=80=98window-body-width=E2=80=99 now. > ). The function > `window-total-width' returns the window width *with* fringes, scroll > bars and right divider. > > Such a function would be useful for packages that calculate some value= > that depends on the width of the window, which often end up using a ba= d > value if the window has wide margins (e.g., windows showing buffers > where `visual-fill-column-mode' is in use). I have made several bug > reports / pull requests to packages asking them to use > `window-total-width' instead of `window-width' (which is an alias for > `window-body-width'), and most have been kind enough to make the chang= e, > but my pull request to popwin.el[3] was rejected because the window > configuration wasn't always restored properly after closing the popup > window. This seems to be the result of using `window-total-width', > because using a custom function that returns justh the text width + > margins works fine (i.e., all of popwin.el's ERT tests now pass[4]). > > Such a function would probably make sense for the other packages that > (now) use `window-total-width' as well, because what these packages > generally need to know is the maximum *potential* width of the text > area. The greatest problem I have with a function returning the combined size of text area and margins is that it would leave out the fringes. Hence such a function would by default _not_ return the size of a contiguous area on the screen which I personally would find slightly disconcerting. But if you send us such a function (say =E2=80=98window-text+margins-widt= h=E2=80=99) and nobody objects I'll install it. martin