From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 25 08:07:51 2015 Received: (at submit) by debbugs.gnu.org; 25 Nov 2015 13:07:51 +0000 Received: from localhost ([127.0.0.1]:52163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1Znb-0003PK-Cd for submit@debbugs.gnu.org; Wed, 25 Nov 2015 08:07:51 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48006) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1ZnY-0003P8-I5 for submit@debbugs.gnu.org; Wed, 25 Nov 2015 08:07:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1ZnS-0003ix-CL for submit@debbugs.gnu.org; Wed, 25 Nov 2015 08:07:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ZnS-0003it-8o for submit@debbugs.gnu.org; Wed, 25 Nov 2015 08:07:42 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ZnR-000253-Bn for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 08:07:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1ZnL-0003if-Gh for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 08:07:41 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:46987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ZnL-0003iV-9k for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 08:07:35 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1D3182034B for ; Wed, 25 Nov 2015 08:07:32 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 25 Nov 2015 08:07:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=tjwiGurt3945OzMG8Sj0XHgkzKo =; b=KSz76uRsAkuwPFJUmIuC1Auxf2iRhCTAfdVq37sEil+GIBz6DglmbaYpAnZ 0uge02uOp+9gtc8WvwflOlCxk51k+fiGQtqiPJKzUTpJcx8ZJLijC0/oUReLrAMi uSEmwc2mUdIMQIOReBVjAElbv57bev66fXg1AkIKxrIiuXkA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=tj wiGurt3945OzMG8Sj0XHgkzKo=; b=VeuAjfDcghxkq3PQ9s7EdrrnwClouEI2ia 1MxPIa8cwjYF4GddZp5F/XZQ4PcUDPfu3oHwSUIpfaKBZo+nrDeQsx9JdjYpXaGj iGh/Zi4OM3uRhqlsH60H0HGVRFitbXWI4kwgXNKSHA9kAnhxz3xqY8pCV++8N72c gJZcmDLGg= X-Sasl-enc: tZj+yQMUtmuMIFkgI90bcF2LnCKflX43y40ggcDsxg7Q 1448456851 Received: from IdeaPad.messagingengine.com (eruc065.goemobile.de [134.76.38.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 9EDD4C016FB for ; Wed, 25 Nov 2015 08:07:31 -0500 (EST) User-agent: mu4e 0.9.13; emacs 24.5.50.1 From: Joost Kremers To: bug-gnu-emacs@gnu.org Subject: PATCH: Use `window-total-width' in `window-splittable-p' Date: Wed, 25 Nov 2015 14:07:27 +0100 Message-ID: <87io4qgrcg.fsf@fastmail.fm> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) --=-=-= Content-Type: text/plain Following discussion on emacs-devel (thread "Window splitting issues with margins"), this patch replaces the call to `window-width' in `window-splittable-p' with `window-total-width'. This takes the window margins into account when determining if a window can be split horizontally. Note: a similar change to `window-height' isn't necessary, because `window-height' is an alias for `window-total-height'. (Whereas `window-width' is an alias for `window-body-width'.) BTW: this is my first patch. I have no idea if I got all the conventions right... --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-lisp-window.el-window-splittable-p-use-window-total-.patch >From 0fa1f344824530f9ee374cc0d84fa02b61b303bf Mon Sep 17 00:00:00 2001 From: Joost Kremers Date: Wed, 25 Nov 2015 13:36:06 +0100 Subject: [PATCH] * lisp/window.el (window-splittable-p): use `window-total-width' Take the window margins into account when determining if a window can be split horizontally. Copyright-paperwork-exempt: yes --- lisp/window.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/window.el b/lisp/window.el index 6d18905..bcd8922 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -6115,7 +6115,7 @@ window-splittable-p ;; sense nowadays. This can be done more intuitively by ;; setting up `split-width-threshold' appropriately. (numberp split-width-threshold) - (>= (window-width window) + (>= (window-total-width window) (max split-width-threshold (* 2 (max window-min-width 2))))) ;; A window can be split vertically when its height is not -- 2.6.0.GIT --=-=-= Content-Type: text/plain -- Joost Kremers Life has its moments --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 25 12:48:27 2015 Received: (at 22009) by debbugs.gnu.org; 25 Nov 2015 17:48:27 +0000 Received: from localhost ([127.0.0.1]:53045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1eB8-0003rQ-Rv for submit@debbugs.gnu.org; Wed, 25 Nov 2015 12:48:27 -0500 Received: from mout.gmx.net ([212.227.17.22]:51826) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1eB7-0003rI-7e for 22009@debbugs.gnu.org; Wed, 25 Nov 2015 12:48:25 -0500 Received: from [192.168.1.100] ([213.162.68.84]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LiWzQ-1aboPR0420-00cfFS; Wed, 25 Nov 2015 18:48:21 +0100 Message-ID: <5655F45F.4050406@gmx.at> Date: Wed, 25 Nov 2015 18:48:15 +0100 From: martin rudalics MIME-Version: 1.0 To: Joost Kremers , 22009@debbugs.gnu.org Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' References: <87io4qgrcg.fsf@fastmail.fm> In-Reply-To: <87io4qgrcg.fsf@fastmail.fm> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:s8aYqOWhc7D8+8pbAz8OTj0vS5YkuUY8LjCAnhxEnZ0osp4/chU F8Kfq7U/rqFroKYVFJruJhBeNoq90i/hgkN2PuzJzYAoTT0MSVBy/A+cfd6TdEXSKiRcJvB ez+/3bzNmtvFxXelPr1VyWsfMyhdt8Rpnd9cUorhLFPbQIPHL4cxBDscD4ZkaMXcr7+Jch3 lFz3NyKC3CcYBVHXZe9RA== X-UI-Out-Filterresults: notjunk:1;V01:K0:t+Tsek0EMYM=:0ZLzH1qqDWHDKT6V5f67iD IXY2m2U9jKdklZyhj+6hGz0d023SxrPdYiGtYeOE2q4H7NDvNmQmCokjGggrMD/j3PZNk0Cbo di3MdBGURyUUwVOHB7nW0h3J7RFwMjQyO87N4iLNlKO88+Kb0O9sG1w8gSFGV8O5ytn79p1AN 9cJQbsSe7TyBOv8cRDpKVhXU/gOq6btM1KwREAOB/y2mvnA80A5tgMc2cueqM9VPHhsahZeVQ pok5F6nZauruIQHGwbjx+eg73+G4qaY+vL4z/E6NYNL+brEu1mezljTBmfHUKZaGazWLVABH6 AG0hXZsU7rghHOa5mUdQ5vIwsq9DfO5SE5c2dCWm4ffiVhG63UN/rjDHBBW9+hUFPUCxcLEd0 u+dcFdT0vfZQp8rtO+s3zWkamLuZS8NaFeLYDOmVoeVCMODtswapH7YMDcm7jqImVUR8bxi03 86eheORY4TwP5qce1rwFk3SIsDUuhDwP5m9hjrbCLzMfHYujSGuje0+cW+t4huQuZ1J8eZdpi DyJlDRZ2aJkUC80GyppOb3lHAWtQfJR3jrHsZsTnNoWptVLh4UsRLxRm6BKmg8XMqyNP1m4JK iTfFjvwyv7MjZctGDzuUkB2ydj6oCudLr4mDWSk/toBt7g6cpXUUHt1CLVuRSdSvdFkJOwtzu mCFJhXisE83O54EIgsiwUx53lsfPAMM2kk1unsnBZ7N5hJyWarBP9z3LodAcxkQlxMD5LeQnQ APVofsDLoZb1gJ1dbhhk/JLS6ryBYn5NT+rS9JXUfdUY9BcvDI2ulZ+sfGqmhZAaS269oqIuA z/Z1bM8q7PG+ReBSPez/pPkPljuKQ== X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Following discussion on emacs-devel (thread "Window splitting issues > with margins"), this patch replaces the call to `window-width' in > `window-splittable-p' with `window-total-width'. This takes the window > margins into account when determining if a window can be split > horizontally. [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.84 listed in zen.spamhaus.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.84 listed in dnsbl.sorbs.net] X-Debbugs-Envelope-To: 22009 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Following discussion on emacs-devel (thread "Window splitting issues > with margins"), this patch replaces the call to `window-width' in > `window-splittable-p' with `window-total-width'. This takes the window > margins into account when determining if a window can be split > horizontally. [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.84 listed in zen.spamhaus.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.84 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > Following discussion on emacs-devel (thread "Window splitting issues > with margins"), this patch replaces the call to `window-width' in > `window-splittable-p' with `window-total-width'. This takes the window > margins into account when determining if a window can be split > horizontally. If no one objects I'll check it in in a few days. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 25 13:06:34 2015 Received: (at 22009) by debbugs.gnu.org; 25 Nov 2015 18:06:34 +0000 Received: from localhost ([127.0.0.1]:53074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1eSg-0004LG-2M for submit@debbugs.gnu.org; Wed, 25 Nov 2015 13:06:34 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:44773) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1eSd-0004L7-S6 for 22009@debbugs.gnu.org; Wed, 25 Nov 2015 13:06:32 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NYD00I00U7WCI00@a-mtaout22.012.net.il> for 22009@debbugs.gnu.org; Wed, 25 Nov 2015 20:05:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYD00HFQU8CXOB0@a-mtaout22.012.net.il>; Wed, 25 Nov 2015 20:05:01 +0200 (IST) Date: Wed, 25 Nov 2015 20:04:56 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <5655F45F.4050406@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83vb8qvttj.fsf@gnu.org> References: <87io4qgrcg.fsf@fastmail.fm> <5655F45F.4050406@gmx.at> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Wed, 25 Nov 2015 18:48:15 +0100 > From: martin rudalics > > > Following discussion on emacs-devel (thread "Window splitting issues > > with margins"), this patch replaces the call to `window-width' in > > `window-splittable-p' with `window-total-width'. This takes the window > > margins into account when determining if a window can be split > > horizontally. > > If no one objects I'll check it in in a few days. To master, right? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 25 13:15:29 2015 Received: (at 22009) by debbugs.gnu.org; 25 Nov 2015 18:15:29 +0000 Received: from localhost ([127.0.0.1]:53079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1ebI-0004Yv-VU for submit@debbugs.gnu.org; Wed, 25 Nov 2015 13:15:29 -0500 Received: from mout.gmx.net ([212.227.17.21]:62852) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1eay-0004YP-J8 for 22009@debbugs.gnu.org; Wed, 25 Nov 2015 13:15:27 -0500 Received: from [192.168.1.100] ([213.162.68.84]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LiIgB-1afKrT3E6V-00nQI2; Wed, 25 Nov 2015 19:15:04 +0100 Message-ID: <5655FAA2.80406@gmx.at> Date: Wed, 25 Nov 2015 19:14:58 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' References: <87io4qgrcg.fsf@fastmail.fm> <5655F45F.4050406@gmx.at> <83vb8qvttj.fsf@gnu.org> In-Reply-To: <83vb8qvttj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Aaixu698qJS0sC+mBq7rKaIEOJTvPVT0/V2XXzck44NAjtL9DMz o/FofcqKre0WWD8/qKW+achYLgJU6Ecrq+fpJLLllBdx9L1h6VJOO52sLikMdMqFC0aBN6W ipjX++4xLH7hm2TjBGM9/7DfY+lCjD5VHYyEYE2xa/gZWXmAmpJi6ZTQf0omnP/Iljkvfls j4lundYlhWhBDvSMATKbA== X-UI-Out-Filterresults: notjunk:1;V01:K0:E2q0vT3mHKs=:7qCXDH1G/2pA6q8X1K+zt/ I17DON1DXMX3TK0nB1fwYn1wrdtegxcLzB7EZ62p0KLB73H/DEvAAtZQ1fQ2bPBlN34vw7I2F AXjhc/+BrqZ/p1f/AqC8yCypvW5FFn2GNTuirpesqN9fCG2PwJveDNZ8aqCT5I7OmO6QbzL9v Lk+lkafB9DWp4pAL7Jq7cdmG9cD3zDXnfMwreMvA4zPqoBnnmGqoN1CCn/GmYLuxspFkyYHJW iivM0F+pXqcsDSbrasQ4B4Obsn5QFAuHVax0PpQORmrvjgJqTtoLOeTqUuQoc26s1YbCFGKjF rNrGo1xwFdbcMvBUK/XIRTAgQcDXBzVwHgiK3PHf+XQfb0q6cxG4tVjh03IAGPRRle2czIjjs WJ/Qwy3eaA7UxZBgwRFq5DBJx2vDG8gGX1zO/otBPt52/zKMpYYu3xCKmu2IyXegM3HX78iNm /Zn4VgjMcDDfUfl5saQ5oqXHiTgRuduP/riBQU/W+3bDhxTiut5I/czLupSusd0UU+1BUYXhO gxWNIn4uNBgN+Uv8d48RZ1ZY8s2cqlWKcoXnADS4rNRhRMs0fAfoyUP5LGAr6qpMb4Poou78P ukqQzxXJLqPjJcFyG9PKpeN6n99UTmiAjRc0Ikt3Ia3XRHwQT+JUNoHOsaiVxevUyPbhqS4Gp c/Sjo09fwPvYMWOApOII66wLaDBZvE83SP8prAIsYY0krR+qbEJZrXetjNPwgfqXlxmPLc327 9LNHwEQ74TkUj+I3W6MX0ciuwLJ7AHgk8KC8PCrfet0QELN9HXkR409/dzeeLXhuyLtGGcgeB JZb2SG+v/jAiq7UoGRJLB5wbp3QRg== X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> If no one objects I'll check it in in a few days. > > To master, right? To emacs-25 preferably. martin [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.84 listed in dnsbl.sorbs.net] -0.0 SPF_PASS SPF: sender matches SPF record 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.84 listed in zen.spamhaus.org] X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> If no one objects I'll check it in in a few days. > > To master, right? To emacs-25 preferably. martin [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.84 listed in zen.spamhaus.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.84 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record >> If no one objects I'll check it in in a few days. > > To master, right? To emacs-25 preferably. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 25 14:15:55 2015 Received: (at 22009) by debbugs.gnu.org; 25 Nov 2015 19:15:55 +0000 Received: from localhost ([127.0.0.1]:53134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1fXn-0007lL-3C for submit@debbugs.gnu.org; Wed, 25 Nov 2015 14:15:55 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45105) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1fXk-0007lA-U4 for 22009@debbugs.gnu.org; Wed, 25 Nov 2015 14:15:53 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NYD00N00X4E3O00@a-mtaout20.012.net.il> for 22009@debbugs.gnu.org; Wed, 25 Nov 2015 21:15:29 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYD00NKUXHS3L10@a-mtaout20.012.net.il>; Wed, 25 Nov 2015 21:15:29 +0200 (IST) Date: Wed, 25 Nov 2015 21:15:23 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <5655FAA2.80406@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83k2p5x54k.fsf@gnu.org> References: <87io4qgrcg.fsf@fastmail.fm> <5655F45F.4050406@gmx.at> <83vb8qvttj.fsf@gnu.org> <5655FAA2.80406@gmx.at> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Wed, 25 Nov 2015 19:14:58 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > >> If no one objects I'll check it in in a few days. > > > > To master, right? > > To emacs-25 preferably. Convince me. (It doesn't sound like a bug, does it?) From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 03:23:25 2015 Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 08:23:25 +0000 Received: from localhost ([127.0.0.1]:53379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1rpt-0002Hj-5K for submit@debbugs.gnu.org; Thu, 26 Nov 2015 03:23:25 -0500 Received: from mout.gmx.net ([212.227.15.15]:63766) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1rpr-0002Hb-H5 for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 03:23:23 -0500 Received: from [192.168.1.100] ([212.95.7.61]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M6RiN-1aGoPj0QlH-00yRVd; Thu, 26 Nov 2015 09:23:20 +0100 Message-ID: <5656C171.9050506@gmx.at> Date: Thu, 26 Nov 2015 09:23:13 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' References: <87io4qgrcg.fsf@fastmail.fm> <5655F45F.4050406@gmx.at> <83vb8qvttj.fsf@gnu.org> <5655FAA2.80406@gmx.at> <83k2p5x54k.fsf@gnu.org> In-Reply-To: <83k2p5x54k.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:OBByByHJ9UvOBx5tXHNRG2iVUhxOWXW+3YB6dRJl/6xo7Gmp86n VtgQOJLoCBHMWib3LSMVmcYIncFyNFGCSapwq8eCWYFDxSufVXuzhsVJ2jlLMMXSG+FBhfn N8VZXqPMS/so8ZaG7YOJUlfoYD7yzVTzqqFwHvsfTLFkWlG1eYKJt9RdTgmHyRztHNBKMc4 mHtPfan1Ep8XXdLb+1VYg== X-UI-Out-Filterresults: notjunk:1;V01:K0:dm3k6t2DhU8=:teQSkXFSJwdgsISKJPfs72 8Lg3FaOWxkuZiWDSY4FhTjQMOjC6KLfAfdXM/m+StUKTuBNhiu0VkrTf5RmZr+8DWjHyy7CtK zR7RHS77pGZIsA+6iFDhOQSmD3aocHM9/MgUDYYDaFdl4MbTSm5jibOoYMRu6FcnAzLl2vYD9 smqZ/+9gtxcDXZcsZx/DCLkfEwo0AYXIE03L46tLAA9HVBxUsd636rVbuCylUsiKkDGOh5+Wq PBTCJkvMJVFzt645U/aJEf8s0OSRb8NeDpW0pxBx8a/7/gYvruh9oFl7KfIY45ErBSKPQbBk2 ZeTxgvml5dB0w5geW5VBkduXNmjTdR8qAGR6Yo5c1mtCgAt5Tju3bDiItSRtH+dcyvuk6yz6p POVTdNTpqAw1J0Sj18Vnv3yMf7EswmUwZJjUl9DkmeIcv5saByCZvgAOzvXai3+Nh6z9cRb6B sc+HXK2t7KceFGKPQZKNtQdO2c+jpsqHT81tWHxVEHayjyIDuu9z1x789RndKuZEyfymkAheo IZGRhELR7xN3FCvnoKfwnMWRWurpCsSWdmqUooxOEHu2aGkgNsrdvp+tkuFe+sUJ8FxYty2dB MYpMXsYr/wyF2gE0pnc6rU2t9UeSq+5bu0opVkB/pkH0XQC26jk+2cpGdLszuJ54PRFzJdZPH owO2uOzJAXlIQawcyZwv29Iq/PJliHqSmzUV0Ip7iofNr4oeawak9Gk9eLTCib9eWlMqy0YT/ ZIR4p76kYnAw+MpI05qF0GV7WV/mK47lC9cNOCAjmL0XikGWmPez8BVTJjGiOJstsRTHkhUdM 0g2y7le X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Convince me. (It doesn't sound like a bug, does it?) It is a bug. In (>=3D (window-width window) (max split-width-threshold (* 2 (max window-min-width 2)))) we currently compare apples and oranges. =E2=80=98window-width=E2=80=99 = does not include margins, fringes, scrollbar and divider. =E2=80=98window-min-wid= th=E2=80=99 is meant to include them all. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 10:46:55 2015 Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 15:46:55 +0000 Received: from localhost ([127.0.0.1]:54447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1yl4-0006kc-E9 for submit@debbugs.gnu.org; Thu, 26 Nov 2015 10:46:54 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:44966) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1yl1-0006kN-GM for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 10:46:52 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NYF00H00HQ2H200@mtaout25.012.net.il> for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 17:44:05 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYF00HTLIDHKA20@mtaout25.012.net.il>; Thu, 26 Nov 2015 17:44:05 +0200 (IST) Date: Thu, 26 Nov 2015 17:46:34 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <5656C171.9050506@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83r3jcvk4l.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Thu, 26 Nov 2015 09:23:13 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > > Convince me. (It doesn't sound like a bug, does it?) > > It is a bug. In > > (>= (window-width window) > (max split-width-threshold > (* 2 (max window-min-width 2)))) > > we currently compare apples and oranges. ‘window-width’ does not > include margins, fringes, scrollbar and divider. ‘window-min-width’ > is meant to include them all. Thanks. It turns out I was mistaken wrt what issue this attempts to solve. Now that you've set me straight, I agree this is a bug. But I don't necessarily agree with the proposed solution. In the discussion that led to this you said: > > A related problem is the fact that `window-splittable-p' only takes the > > 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 is > > 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. ‘window-splittable-p’ 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 > ...). 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 ... I agree with the asymmetry observation, but I think that the width check is the one that gets it right, while the height check is wrong and should be corrected. When a window is split horizontally, the part that gets split is the text area, not the margins -- those stay at their original size. So when we decide whether to split vertically, we should consider the text-area size, not the total size. Otherwise, we can easily wind up in situations where, due to large margins, a window is split horizontally and the width of its text area becomes ridiculously small. Therefore, I think we should document that split-width-threshold and window-min-width refer to the width of the text area, and if there are functions in window.el that compare them with window-total-width, those places need to be fixed, not this one. We should also fix the height check in window-splittable-p. The modes that triggered this are special in that they adapt their margins to the split, but how would window-splittable-p know that? Perhaps such modes should override that function, or maybe we should provide a hook for them? > BTW: Bug#5944 is about a related issue. I never got around to resolve > it for a similar reason. Did you really mean 5944? That's not an Emacs bug even. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 11:58:25 2015 Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 16:58:25 +0000 Received: from localhost ([127.0.0.1]:54527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1zsG-00005J-QY for submit@debbugs.gnu.org; Thu, 26 Nov 2015 11:58:25 -0500 Received: from mout.gmx.net ([212.227.17.21]:52023) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1zsE-00005B-K1 for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 11:58:23 -0500 Received: from [192.168.1.100] ([213.162.68.43]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lurin-1aSIHY418D-01083w; Thu, 26 Nov 2015 17:58:18 +0100 Message-ID: <56573A22.6070309@gmx.at> Date: Thu, 26 Nov 2015 17:58:10 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' 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> In-Reply-To: <83r3jcvk4l.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:WKesVd+7O3L9FXKsImOmn+8hhB7c+Cq5CJptJ+fUFBMRtDyEjqq DA6yQLxfZi2fgV4+UdEbDsX58A/Vny4AzJiGiGWqEztSy2P5Nmv3hzbQ/8+js6KkMe+kyjB uAn5I1Swm7VaxxclQZezZi4srwQh2FqoYV9gF6V4OAB45zNHAPoyLu2wEh6rhyeUDqjG52E u84RhJ1nUNU4o4Z3qnBLw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tGqnS+iyJKk=:QA9h5zbecxghxV2ohmRW9Q OprifgxyaFyDWh6cIT8m5CskY90LMjcUmxTqtnNi2lK77kAzZ40QtX7gJ7tmyDwEn1K+F5ZpN kwYPtzpXZ6DRr0aKq2IdtTPacRV72OXn/cxMaTgejepwMdxC67aJzG6iFPR35IqZWF3arP131 UucUeARz8aHUSnKl71+NBdZm1i3HHz33Ba6Dl45/f3kjUizO0W1HpZvnR2EyMs21FJpOGo7H0 4FERfvMav8Y2RosxA+Nn6CBLGQnT71TJCxeGHxrXvj5j/Qj1rBUoU3wNPdbhhtcZ3HFsAZw/C c6hoUKMFYwioMN+0bYwnZsVC9djWV6OmDUi4EIot6uSmmYQ3TPfgNfwxbQ4B+Y+rGyq1JfuzE 0FXi2BaJMAjtsu/Y1QpCuSIYjctAu3cbnoHcNU7vr3HTn7xa/2DHc06frXYx6bebvrELDImZK Oe3Ez9/VOPeF9sHuqfJmpGeh4/R/T9v6JBj+X7bsYr3eQKaGdS/dld8Wpmmk2Dpha9zsUMS7N 49vjWRHvoZmQdjovTX53LDkqt8lUGI0dfpR4T1xWQf0F8vIyHrRHmldM+pK3ZiQTvzkOgHzNl Y0mQKoLh4VsAE2gUeDE+Ao9LXltZvtNIC2GbrZi+xag1Lmo7T35/uvm1H4Lb6ra4xAa7rO3/w 4/XfkNMPXrYnWXuvSp2hhCToT3X4sxX6aXmnPC0Xumi/Qt7gJ6Hw3bhBsAbeBGHOAsPfbtpZj ZpuJko2hR9/y95XdHfKJuGsSqxHL2EiMEy8ZF++l+rmbZSi5PRNtIbrS+VAZYbePE3fn0v5G+ SBVXnraBlSQqSnEAJEpu9qV4/G2lQ== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > I agree with the asymmetry observation, but I think that the width > check is the one that gets it right, while the height check is wrong > and should be corrected. When a window is split horizontally, the > part that gets split is the text area, not the margins -- those stay > at their original size. Note that =E2=80=98window-splittable-p=E2=80=99 is exclusively used by =E2= =80=98display-buffer=E2=80=99 and the probability is very high that the new window will not be used for displaying the buffer of the original window. The new window will very likely have its own margins and header line. > So when we decide whether to split > vertically, =2E.. horizontally ... > we should consider the text-area size, not the total size. > Otherwise, we can easily wind up in situations where, due to large > margins, a window is split horizontally and the width of its text area= > becomes ridiculously small. This is a problem that bites us much more with =E2=80=98split-window=E2=80= =99 than with =E2=80=98display-buffer=E2=80=99. As a matter of fact it has been alread= y addressed in one of the present threads discussing margins. My opinion is that modes that manage wide margins have to handle this in the hooks called when windows are split, deleted or resized. They also calculate the size of the margins based on the current window width when they get activated. > Therefore, I think we should document that split-width-threshold and > window-min-width refer to the width of the text area, and if there are= > functions in window.el that compare them with window-total-width, > those places need to be fixed, not this one. We should also fix the > height check in window-splittable-p. =E2=80=98window-min-width=E2=80=99 (and all related variables and functio= ns) refer to the total width of windows. Changing its semantics would constitute quite some effort. > The modes that triggered this are special in that they adapt their > margins to the split, but how would window-splittable-p know that? > Perhaps such modes should override that function, or maybe we should > provide a hook for them? This is not mode-triggered. =E2=80=98window-splittable-p=E2=80=99 is use= d by =E2=80=98display-buffer=E2=80=99 to find the place for displaying *help*,= *info*, *completions*, ... >> BTW: Bug#5944 is about a related issue. I never got around to resolv= e >> it for a similar reason. > > Did you really mean 5944? That's not an Emacs bug even. It's bug#17065, which talks about line 5944 of window.el. And I think you might agree with the poster ;-) martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 12:26:08 2015 Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 17:26:08 +0000 Received: from localhost ([127.0.0.1]:54585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a20J5-0000ox-Sv for submit@debbugs.gnu.org; Thu, 26 Nov 2015 12:26:08 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:57400) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a20J3-0000op-Ms for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 12:26:06 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NYF00D00MRVJR00@mtaout29.012.net.il> for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 19:25:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYF003X6N2KBXA0@mtaout29.012.net.il>; Thu, 26 Nov 2015 19:25:32 +0200 (IST) Date: Thu, 26 Nov 2015 19:25:49 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <56573A22.6070309@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <8337vsvfj6.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Thu, 26 Nov 2015 17:58:10 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > > I agree with the asymmetry observation, but I think that the width > > check is the one that gets it right, while the height check is wrong > > and should be corrected. When a window is split horizontally, the > > part that gets split is the text area, not the margins -- those stay > > at their original size. > > Note that ‘window-splittable-p’ is exclusively used by ‘display-buffer’ > and the probability is very high that the new window will not be used > for displaying the buffer of the original window. The new window will > very likely have its own margins and header line. Is it forbidden to call that function from any other Lisp? If so, disregard what I wrote. But if not, window-splittable-p should do a correct job no matter who calls it, do you agree? > > we should consider the text-area size, not the total size. > > Otherwise, we can easily wind up in situations where, due to large > > margins, a window is split horizontally and the width of its text area > > becomes ridiculously small. > > This is a problem that bites us much more with ‘split-window’ than with > ‘display-buffer’. As a matter of fact it has been already addressed in > one of the present threads discussing margins. My opinion is that modes > that manage wide margins have to handle this in the hooks called when > windows are split, deleted or resized. They also calculate the size of > the margins based on the current window width when they get activated. My text that you quoted here talks about the "normal" case, where the margins stay put upon splitting windows. I'm saying that in such a situation a decision made using the total width could be terribly wrong. > > Therefore, I think we should document that split-width-threshold and > > window-min-width refer to the width of the text area, and if there are > > functions in window.el that compare them with window-total-width, > > those places need to be fixed, not this one. We should also fix the > > height check in window-splittable-p. > > ‘window-min-width’ (and all related variables and functions) refer to > the total width of windows. Changing its semantics would constitute > quite some effort. If it's complicated, let's do that on master. But do it we must, IMO. > > The modes that triggered this are special in that they adapt their > > margins to the split, but how would window-splittable-p know that? > > Perhaps such modes should override that function, or maybe we should > > provide a hook for them? > > This is not mode-triggered. In my text, "this" referred to this bug report. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 13:06:21 2015 Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 18:06:21 +0000 Received: from localhost ([127.0.0.1]:54649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a20w1-0001q5-38 for submit@debbugs.gnu.org; Thu, 26 Nov 2015 13:06:21 -0500 Received: from mout.gmx.net ([212.227.17.22]:50647) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a20vz-0001pw-6b for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 13:06:19 -0500 Received: from [192.168.1.100] ([213.162.68.43]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwF9u-1aOg3c3GaU-0186HG; Thu, 26 Nov 2015 19:06:14 +0100 Message-ID: <56574A0F.101@gmx.at> Date: Thu, 26 Nov 2015 19:06:07 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' 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> In-Reply-To: <8337vsvfj6.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:stw+vTGVzW25iWG8CPlr4Oo4I6UDRg2SWfuB/TBJHCzXeAyn+Uu eBjyFIxxdtiIaOKf88oREOxV+ds/wVpcmBMeSSwZlIEPbu9YmNb+N85357K7TpMyrKyr3eb +C1RuG4NAUkBjEHk9nL2WKRblD3O9csg1ptgJoNKwVjCVbwpu+hrNk0w5cv7daVBi5u/jfz j0w5mDzFa74grPniceQRw== X-UI-Out-Filterresults: notjunk:1;V01:K0:VDiqGaMNUXc=:dI79FQvlLwjydF+/RAjDah b/PYfRhYgVhmpvkf6VAwV8F5Z6UWPOjw74gL3UoIJGEGgp/7xkyr/vpuYJMwR94KjU9vYGDGC clcO0Cs5+R/RxEt4dK1+wlkB+OAkoDa6VlfbzVo9hzjLdUmZyo9nCCt64VCpTJzxoWmj8U2IZ F96Z26SFQfHpRM+wKRmY0LLCM2yhPb4ghYPX+ZUlWBDRwmq+Dq0+GHOHVJu90TPfjePCV6uQ5 i60WFMir7V5716NfejX6HF7JJU15gaD9AqAhgwuhMKthmfigCPB4K4/xgoTTVdZ5R/ZJpZ7FZ RSMHvAkllvhHtr71fhc5Zd/5li/eC0jcNafsn7/+44XZsLW2M8JCQzu/oumDPjHcjy3ypuBza KJE2BcDc+8n7pI47fgrfPd7mAzVex6Ti+bxcudyiYSvzwm+jaVy9z9ophkPwEMwu83UTD0k0k zwoQZ+jHqaFkq+7WJ+9/Ah4M9uXPI/xDZ0cGUteVDfllmOMJGv7/ma8BECOtgT6Xw0kn2ujo0 yhIgX+74VP4QLcOTkC9xoc5SagvgWYJooCWV9eT/fgatVDJFbx1I6vBcrAe69ADpgFUEfHrwC Jrr0R3GazIcdIWWgf904ZhBVLcmFO3Lm/4jgxmWpnCbOJZ1q68oTNZcj7pY8Jgmq4FnAwg2t+ KKfjwrDu0z9m0lRu9yJ9xOYG/xhy4VwcWEGGkCWyGF6x99tf7EKw78jVSneOjN+EW1SXINV0z Of4o44lcEycotcWEUY1A9S1vs3WAbT5X5e9TK6IchrdSAy9nNAI0yEnMBXFO6nFFrHJuSDvXP aOy1+/QIHOsvwCQdUNMosfLXIZeiw== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) >> Note that =E2=80=98window-splittable-p=E2=80=99 is exclusively used b= y =E2=80=98display-buffer=E2=80=99 >> and the probability is very high that the new window will not be used= >> for displaying the buffer of the original window. The new window wil= l >> very likely have its own margins and header line. > > Is it forbidden to call that function from any other Lisp? If so, > disregard what I wrote. But if not, window-splittable-p should do a > correct job no matter who calls it, do you agree? Presently =E2=80=98window-splittable-p=E2=80=99 is misnamed and I think t= hat's the main cause of the confusion. But its doc-string clearly names =E2=80=98split-window-sensibly=E2=80=99 as the caller (which is misnamed = as well but all of these were written before =E2=80=98display-buffer=E2=80=99 was reorgan= ized). In any case both functions belong exclusively to =E2=80=98display-buffer=E2=80=99= and are not related to C-x 3. > My text that you quoted here talks about the "normal" case, where the > margins stay put upon splitting windows. I'm saying that in such a > situation a decision made using the total width could be terribly > wrong. But the "normal" case where this happens is C-x 3 and there the mode that created the large margins should adapt. >> =E2=80=98window-min-width=E2=80=99 (and all related variables and fun= ctions) refer to >> the total width of windows. Changing its semantics would constitute >> quite some effort. > > If it's complicated, let's do that on master. But do it we must, IMO.= Basically it would amount to =E2=80=98split-window-horizontally=E2=80=99 = telling us that it can't split the window. Which might not be the intention of the user who expects the margins (whose sole purpose is to center the text in the window) to shrink accordingly. But honestly I don't know which implications changing the semantics of =E2=80=98window-min-width=E2=80=99 could have. I could imagine adding a = new option say =E2=80=98window-min-text-width=E2=80=99 and have the resizing routines re= spect this as far as possible. But sanitizing window sizes when, for example, making a frame very small, would have to ignore such an option anyway. The text area is the only part I can freely shrink and enlarge down to one line and two columns. I cannot restore previous fringes, margins and scroll bars once I have shrunk them because I don't remember their previous size. And adding for every window a slot, say previous_left_fringe_width, remembering it in window configurations, setting it when a user sets =E2=80=98set-window-fringes=E2=80=99 in between is something I'm not incl= ined to do. >> > The modes that triggered this are special in that they adapt thei= r >> > margins to the split, but how would window-splittable-p know that= ? >> > Perhaps such modes should override that function, or maybe we sho= uld >> > provide a hook for them? >> >> This is not mode-triggered. > > In my text, "this" referred to this bug report. If you mean that a mode introducing large margins should override =E2=80=98split-window-sensibly=E2=80=99 then this is not TRT. =E2=80=98s= plit-window-sensibly=E2=80=99 is user territory and =E2=80=98window-splittable-p=E2=80=99 too. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 13:37:06 2015 Received: (at 22009) by debbugs.gnu.org; 26 Nov 2015 18:37:06 +0000 Received: from localhost ([127.0.0.1]:54657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a21Pm-0002dj-2K for submit@debbugs.gnu.org; Thu, 26 Nov 2015 13:37:06 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:57306) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a21PR-0002cz-L5 for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 13:37:04 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NYF00M00Q9LSI00@mtaout26.012.net.il> for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 20:39:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYF00KB9QHY7N30@mtaout26.012.net.il>; Thu, 26 Nov 2015 20:39:34 +0200 (IST) Date: Thu, 26 Nov 2015 20:36:28 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <56574A0F.101@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83wpt4txoz.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Thu, 26 Nov 2015 19:06:07 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > >> Note that ‘window-splittable-p’ is exclusively used by ‘display-buffer’ > >> and the probability is very high that the new window will not be used > >> for displaying the buffer of the original window. The new window will > >> very likely have its own margins and header line. > > > > Is it forbidden to call that function from any other Lisp? If so, > > disregard what I wrote. But if not, window-splittable-p should do a > > correct job no matter who calls it, do you agree? > > Presently ‘window-splittable-p’ is misnamed and I think that's the main > cause of the confusion. But its doc-string clearly names > ‘split-window-sensibly’ as the caller (which is misnamed as well but all > of these were written before ‘display-buffer’ was reorganized). In any > case both functions belong exclusively to ‘display-buffer’ and are not > related to C-x 3. > > > My text that you quoted here talks about the "normal" case, where the > > margins stay put upon splitting windows. I'm saying that in such a > > situation a decision made using the total width could be terribly > > wrong. > > But the "normal" case where this happens is C-x 3 and there the mode > that created the large margins should adapt. > > >> ‘window-min-width’ (and all related variables and functions) refer to > >> the total width of windows. Changing its semantics would constitute > >> quite some effort. > > > > If it's complicated, let's do that on master. But do it we must, IMO. > > Basically it would amount to ‘split-window-horizontally’ telling us that > it can't split the window. Which might not be the intention of the user > who expects the margins (whose sole purpose is to center the text in the > window) to shrink accordingly. > > But honestly I don't know which implications changing the semantics of > ‘window-min-width’ could have. I could imagine adding a new option say > ‘window-min-text-width’ and have the resizing routines respect this as > far as possible. Maybe we should step back and recall what problem are we trying to solve with the proposed patch, then. > >> > The modes that triggered this are special in that they adapt their > >> > margins to the split, but how would window-splittable-p know that? > >> > Perhaps such modes should override that function, or maybe we should > >> > provide a hook for them? > >> > >> This is not mode-triggered. > > > > In my text, "this" referred to this bug report. > > If you mean that a mode introducing large margins should override > ‘split-window-sensibly’ then this is not TRT. ‘split-window-sensibly’ > is user territory and ‘window-splittable-p’ too. Didn't you just tell they are called by display-buffer? How's that "user territory"? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 26 20:16:49 2015 Received: (at 22009) by debbugs.gnu.org; 27 Nov 2015 01:16:49 +0000 Received: from localhost ([127.0.0.1]:54810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a27eb-0003xi-BP for submit@debbugs.gnu.org; Thu, 26 Nov 2015 20:16:49 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:36675) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a27eG-0003xH-Vq for 22009@debbugs.gnu.org; Thu, 26 Nov 2015 20:16:47 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8D53420A68 for <22009@debbugs.gnu.org>; Thu, 26 Nov 2015 20:16:28 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 26 Nov 2015 20:16:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=SC23XjNeifq102OFtT5ZZ8btNIg =; b=aYq7L5rKTpXtfaoRX+dTuTVAkIQxMOuVODtffcwpGQl1iNvPdbWTSlKuk13 PdORTJHf/nOLHdgnhDVGrnS5+Y/rN+GLcdVdImfUGiEW/RrYa7D+HMnt9ov5qaim RlDR87PNeHQ1g7mJtPSYWB3j9MXr2VXAVM38IzZAXXeqyTZ8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=SC 23XjNeifq102OFtT5ZZ8btNIg=; b=oZNcZyelDsAhchCqWq+fEw0YNtGJ0d7haV nKNTBXWEOxsP34n1XhlQrT+JscIYCcnsFXs3Z5FFu2wr5WF3nkqsZnEgt/i7qCeW 3ub65JhYpCaJtcWvrQDyx8gKgSYmZEEtG7COcqINjCq+3NPkNGyIXzhPJVKy7UgG fNukOzFFE= X-Sasl-enc: abxw3+bN+KmYNZWGrY0B8WdEeArh+leyyoCgWvX9+CkA 1448586988 Received: from IdeaPad.messagingengine.com (x5f7750b2.dyn.telefonica.de [95.119.80.178]) by mail.messagingengine.com (Postfix) with ESMTPA id E869EC016DB for <22009@debbugs.gnu.org>; Thu, 26 Nov 2015 20:16:27 -0500 (EST) User-agent: mu4e 0.9.13; emacs 24.5.50.1 From: Joost Kremers To: 22009@debbugs.gnu.org Subject: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' Date: Fri, 27 Nov 2015 02:16:22 +0100 Message-ID: <87lh9kw8bd.fsf@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) [My apologies if this message messes up threading. I accidentally deleted the thread from my mail archive.] Eli Zaretskii wrote: > Maybe we should step back and recall what problem are we trying to > solve with the proposed patch, then. The problem I'd like to solve (and the reason I submitted the patch) is that if a window has wide margins that are used to center the text, `window-splittable-p' will say that the window cannot be split horizontally, even though it can, because the margins are disposable. But actually, that's not the real problem. The real problem is that `window-splittable-p' simply has too little information to make an informed decision. The point is that the margins may be used for two different kinds of purposes: (1) The margins can be used to display useful information, in which case they should be retained when the window is split. (2) The margins can be used to reduce the width of the text area. In this case, the margins are disposable. Right now, `window-splittable-p' does the right thing for case (1), but not for case (2). With the patch I submitted, it would do the right thing for case (2), but no longer for case (1). So I agree it's actually a bad patch. The only way to deal with both (1) and (2) correctly, and also with the case where different modes use the margins for (1) and (2) *at the same time*, would be to store information about the modes that use the margins and for which purpose. Then `window-splittable-p' could tell which part of the margins must be retained and which part is disposable. We were discussing just such a proposal on emacs-devel, so perhaps it would be best to continue the discussion there? -- Joost Kremers Life has its moments From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 27 03:27:54 2015 Received: (at 22009) by debbugs.gnu.org; 27 Nov 2015 08:27:54 +0000 Received: from localhost ([127.0.0.1]:55035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2ENm-00068B-17 for submit@debbugs.gnu.org; Fri, 27 Nov 2015 03:27:54 -0500 Received: from mout.gmx.net ([212.227.17.20]:62953) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2ENj-000683-OL for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 03:27:52 -0500 Received: from [192.168.1.100] ([213.162.68.32]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M2L60-1aL8HH2q8K-00sASk; Fri, 27 Nov 2015 09:27:47 +0100 Message-ID: <565813FB.6040604@gmx.at> Date: Fri, 27 Nov 2015 09:27:39 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' 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> In-Reply-To: <83wpt4txoz.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:/q+gdBFIRA86GEHLdcTc5LCazhKQWriTHxVHQy6tO1Ga6d6W5Ch 7+mpHRa9Hv1Ok1dRdQUW8vGO3z3aEiqNC4QGx2WN5bnDlE4+uoCrMOdDhugKNNR0SkEDTuf Q08T583HJ6jbdVITB5kS3TwmXc4WIrj3qs6NmiPfXEPMR+WPD6nmjNnQINcqUhGXoJ/k6jf EohxK59Ze0gB381r0nrRQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:VPj+b+SrMs0=:UlDED5ogN2IAYwBKX/VwMu cqcG3PZcijBEbmTJQ9yL+k0e8G4O/5CmL+o8CNUFvOOPBQ+8C3mgXKTK1Z//IdISzFM6IyCfw 5pTZuThI0yDWaIO3bQX6Gw3SE+WjKq0ZtBimoUeNbJPfob+oiYTW2ozT7FtrDpP4u0vY9P/UH E3XL43C27o8ZXFrlLXAZF4fNXzfD+jKstR8qu/CO8DhDMlkY8AqZ8CQRLddH/SguMwoSsjSyu j5WvAQHozEhl30/5j3AU1ZYQXu/ddKcj9VYqDtF5W+tMN1CmFNSIEOyN8Hi0HQ+vHAbNlEMPP TyUe0fzuQqcoAD5CT1soAYI085XUSU7aIaaeyXuRFluf1KEw2S1q94UKtS5tcexi6hwiXCxTm fbPms49gbv8yv3OjDGelxrMLd+toKovPzTZNUd9ihSWwmO7/igtCqmhYGM65kBuNp/rw0C6g3 3NfggWKxPwAPFOtmg4X9p7YRygWychqvEibq3YF3TkpW3ENC+izfVvrLkaw6UvkWkWqEgHJk6 r+T6/MiFFUJcM3wl85+KSNeOjLBYw3sPrBfRNjsbZrsYRHlEccKQQ6ONjOvvu2Xh1k0roPMS3 BYF7iSxMkROmq7IyJIo+gw79iZ3NDMrIlIOXWVDdAMCcmsKzSBqZZ0pkZSTmdmc69mh+bfy1L CUmn1VSXl6Zr5bCx0PAKpFasuWlCqCFNvyTUIcKXWBMxo3R+qHlmJZkOBmE/tc23Whx0cWcJo KHezlEeSNqjtREIk3P8KD3LsFZ/+8yG9EzzpSFvzjtypPuWcCCZ22YDaeRoPYp31cfdvifaXC MX8MFamGScFvzBI3chq2ln5323Pwg== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > Maybe we should step back and recall what problem are we trying to > solve with the proposed patch, then. The current code is inherently wrong because it treats height and width differently. And it's not about the margins alone but also about fringes, scroll bars and dividers. But this is a very old inconsistency and I never worried to much about it. Joost uncovered it. >> If you mean that a mode introducing large margins should override >> =E2=80=98split-window-sensibly=E2=80=99 then this is not TRT. =E2=80= =98split-window-sensibly=E2=80=99 >> is user territory and =E2=80=98window-splittable-p=E2=80=99 too. > > Didn't you just tell they are called by display-buffer? How's that > "user territory"? The option =E2=80=98split-window-preferred-function=E2=80=99 is by defaul= t set to =E2=80=98split-window-sensibly=E2=80=99. It's exclusively in the hand of= the user to change that. A mode that wants to change whether and how =E2=80=98display-buffer=E2=80=99 is supposed to split a window should spe= cify its own buffer display action in the call to =E2=80=98display-buffer=E2=80=99. It would be more correct to rename =E2=80=98split-window-preferred-function=E2=80=99 -> =E2=80=98display-buf= fer-split-window-preferred-function=E2=80=99 =E2=80=98split-window-sensibly=E2=80=99 -> =E2=80=98display-buffer-split-= window-sensibly=E2=80=99 =E2=80=98window-splittable-p=E2=80=99 -> =E2=80=98display-buffer-window-s= plittable-p=E2=80=99 in order to avoid the misunderstandings we have here. But this is clumsy. Suggestions welcome. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 27 03:28:33 2015 Received: (at 22009) by debbugs.gnu.org; 27 Nov 2015 08:28:33 +0000 Received: from localhost ([127.0.0.1]:55039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2EOO-00069Q-FQ for submit@debbugs.gnu.org; Fri, 27 Nov 2015 03:28:32 -0500 Received: from mout.gmx.net ([212.227.17.22]:50794) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2EOM-00069I-FR for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 03:28:31 -0500 Received: from [192.168.1.100] ([213.162.68.32]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MD9uq-1a5YIw3PvY-00GVPa; Fri, 27 Nov 2015 09:28:26 +0100 Message-ID: <56581423.6010607@gmx.at> Date: Fri, 27 Nov 2015 09:28:19 +0100 From: martin rudalics MIME-Version: 1.0 To: Joost Kremers , 22009@debbugs.gnu.org Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> In-Reply-To: <87lh9kw8bd.fsf@fastmail.fm> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:2TcCeMdbY6y21EfIk9qP7+sYdXW8GA3mt8Dlo0vp/LoDeJCYZc9 mniga7G3gjpeocZZ4Zi1hFrBnks+M4OO7fFHJu6Os4aZNu+J72eFWSrRab3cRchJuQbngqQ zJB3w7NHkUKUmKF9E65LySVQ2dsVZoWupwx2IqPfFyrU8gX6ShNE5PhtaZ8fNsVP1ZY1MUh lwUqoWFACY8rb99ZZu28w== X-UI-Out-Filterresults: notjunk:1;V01:K0:7i0UvNGIQT4=:jJvxWxBgrLbqlMgvfOqips Cu8XTj+qabLTr4hYHL8MthM//jgqOmgPB8jHSKv/GmlqcIHC+gNDY7AeIoZyKxah0PUwyyRY8 dNorRKklVzZKa45TC4pVYxs1zKO70k9OYAlKlqp7iP9JcPJ6ODXWNicZX+m+qiH9y9wRax0wv wNJaUu4ITsIVJcHnf2qBqEw8i9u8d0LLBmrSz0G8mh+Ja9ABvjzc/d6SVlguiFkb7zE/k/6/f aHeIXeSX4h1ZAS76R2W/UHjD8qrci2h1dEEmTdGYhpNRBwxXOsh7v0zgFHGM/EXSLZ90dXQfo CG2xVXpJlFc+NfH0Q2zNCZ7NETg8zNcO7vAs6Dr3PhrOxK6TgcNuaVV1NJ+HtiD+HLc/x4Nya iLVYndBEPaTSyiqyskKi+xHPo3MepGyrzpfW4IedHYxQNnzGIwvvs7cVFML7iBxOB4X8VJSPH pXnRQVnJ8cIB5RXo9in53XfRBadHYGEHBJMCoyQo/4UxOaiAm2yxfe5B97ea/9pPdyjXo7P8Q jOIs9AmQu54596etVNQaCBTfMvKbV4mt3iimaBsWMuK4SM1gLhJlQ71j19i2lMYasWF1QbJUA iBTeSw9Uo2i28TamJGxO7ujKnw8HOe3vbgQJGUwQHSu7O6EpPiZ2FyRuBzKC6eIXdZqALxofi 1lSGZ6LcuXyKughCUPczNK9IrvEjRhjlL5CImccBsZBjRzdSLDPum4TvQuG2skd+spzSoLiZJ a4KC0dB2x7cwDvQP4V0x/a9ifVzp2Qj7Xp2KSeJVWlXlcvoXW0jtDLzU2Kw76Yu5byfps0yPc 6S0iGZymZCxkPSyJhZOM1gQQmyg6Q== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 22009 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > The problem I'd like to solve (and the reason I submitted the patch) i= s > that if a window has wide margins that are used to center the text, > `window-splittable-p' will say that the window cannot be split > horizontally, even though it can, because the margins are disposable. > > But actually, that's not the real problem. The real problem is that > `window-splittable-p' simply has too little information to make an > informed decision. > > The point is that the margins may be used for two different kinds of > purposes: > > (1) The margins can be used to display useful information, in which ca= se > they should be retained when the window is split. But =E2=80=98window-splittable-p=E2=80=99 is used in a context where usua= lly we use the new window to display another buffer than that of the original window. To my knowledge nobody wants *help* or *completions* buffers to display line numbers. And if the original window has no margins but the new window should display them, the current code won't help either. > (2) The margins can be used to reduce the width of the text area. In > this case, the margins are disposable. Let's specify the reason more explicitly: The margins are used to center the text area in the window. Correct? > Right now, `window-splittable-p' does the right thing for case (1), It usually does not as I tried to sketch above. > but > not for case (2). With the patch I submitted, it would do the right > thing for case (2), but no longer for case (1). So I agree it's actual= ly > a bad patch. > > The only way to deal with both (1) and (2) correctly, and also with th= e > case where different modes use the margins for (1) and (2) *at the sam= e > time*, would be to store information about the modes that use the > margins and for which purpose. Then `window-splittable-p' could tell > which part of the margins must be retained and which part is disposabl= e. It would have to be clairvoyant wrt which kind of margins the buffer displayed in the new window will have. =E2=80=98find-file=E2=80=99 can e= nable =E2=80=98linum-mode=E2=80=99 in =E2=80=98find-file-hook=E2=80=99 but the = real width of the margin needed to display them will be known only when =E2=80=98linum-mode=E2=80=99 calc= ulates it, that is, _not_ at the time of splitting. > We were discussing just such a proposal on emacs-devel, so perhaps it > would be best to continue the discussion there? That thread is for Emacs 26. Here we have to decide how to proceed with Emacs 25. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 27 15:52:06 2015 Received: (at 22009) by debbugs.gnu.org; 27 Nov 2015 20:52:06 +0000 Received: from localhost ([127.0.0.1]:56495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2Pzx-0004hI-9v for submit@debbugs.gnu.org; Fri, 27 Nov 2015 15:52:05 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:42056) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2Pzs-0004gd-Ld for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 15:52:02 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NYH00A00QA7FO00@mtaout29.012.net.il> for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 22:51:30 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYH0052IR9SNR70@mtaout29.012.net.il>; Fri, 27 Nov 2015 22:51:29 +0200 (IST) Date: Fri, 27 Nov 2015 22:51:45 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <565813FB.6040604@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83oaefqi72.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Fri, 27 Nov 2015 09:27:39 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > > Maybe we should step back and recall what problem are we trying to > > solve with the proposed patch, then. > > The current code is inherently wrong because it treats height and width > differently. And it's not about the margins alone but also about > fringes, scroll bars and dividers. But this is a very old inconsistency > and I never worried to much about it. Joost uncovered it. 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. So why should we do anything about window-splittable-p if it only affects functions that are not relevant to Joost's use case? Hence my question: if we aren't fixing Joost's use case, and display-buffer is not relevant to splitting windows with large margins, what problem we are trying to solve with that patch? More importantly, if there isn't a clear-cut use case that will allow us to decide which is the correct behavior, how can we decide whether to make this change on master or on the release branch? And why did you feel it was so important to fix it on the branch? What's the urgency? > >> If you mean that a mode introducing large margins should override > >> ‘split-window-sensibly’ then this is not TRT. ‘split-window-sensibly’ > >> is user territory and ‘window-splittable-p’ too. > > > > Didn't you just tell they are called by display-buffer? How's that > > "user territory"? > > The option ‘split-window-preferred-function’ is by default set to > ‘split-window-sensibly’. It's exclusively in the hand of the user to > change that. A mode that wants to change whether and how > ‘display-buffer’ is supposed to split a window should specify its own > buffer display action in the call to ‘display-buffer’. OK, and I'm still asking: how is all that related to window-splittable-p? When we talk about that function, what is the relevance of the user's ability to replace it to the discussion? > It would be more correct to rename > > ‘split-window-preferred-function’ -> ‘display-buffer-split-window-preferred-function’ > > ‘split-window-sensibly’ -> ‘display-buffer-split-window-sensibly’ > > ‘window-splittable-p’ -> ‘display-buffer-window-splittable-p’ > > in order to avoid the misunderstandings we have here. And how is this renaming relevant to the patch that is being discussed? I should probably bail out of this discussion, because I feel I'm not contributing anything but my own confusion to it. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 27 15:56:46 2015 Received: (at 22009) by debbugs.gnu.org; 27 Nov 2015 20:56:46 +0000 Received: from localhost ([127.0.0.1]:56502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2Q4U-0004rL-95 for submit@debbugs.gnu.org; Fri, 27 Nov 2015 15:56:46 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:50692) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2Q4S-0004rA-EV for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 15:56:45 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NYH00I00R4XC500@a-mtaout23.012.net.il> for 22009@debbugs.gnu.org; Fri, 27 Nov 2015 22:56:43 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYH00ITORIIAY20@a-mtaout23.012.net.il>; Fri, 27 Nov 2015 22:56:43 +0200 (IST) Date: Fri, 27 Nov 2015 22:56:30 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <87lh9kw8bd.fsf@fastmail.fm> X-012-Sender: halo1@inter.net.il To: Joost Kremers Message-id: <83mvtzqhz5.fsf@gnu.org> References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > From: Joost Kremers > Date: Fri, 27 Nov 2015 02:16:22 +0100 > > The problem I'd like to solve (and the reason I submitted the patch) is > that if a window has wide margins that are used to center the text, > `window-splittable-p' will say that the window cannot be split > horizontally, even though it can, because the margins are disposable. > > But actually, that's not the real problem. The real problem is that > `window-splittable-p' simply has too little information to make an > informed decision. > > The point is that the margins may be used for two different kinds of > purposes: > > (1) The margins can be used to display useful information, in which case > they should be retained when the window is split. > > (2) The margins can be used to reduce the width of the text area. In > this case, the margins are disposable. There's one more factor here: whether the margins will remain at their width after splitting. The mode which you presented and where the current behavior was a problem changed the margins width as result of the split (AFAIU), which is something the split decision cannot possibly know. So I don't see how we could solve the problem even in principle if we want to handle such modes correctly. The only way is to ask the modes themselves, or provide a hook for them to override the decision. > We were discussing just such a proposal on emacs-devel, so perhaps it > would be best to continue the discussion there? Probably. And I still think such changes are not for the release branch. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 28 05:26:21 2015 Received: (at 22009) by debbugs.gnu.org; 28 Nov 2015 10:26:21 +0000 Received: from localhost ([127.0.0.1]:57601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2chx-0000DD-5V for submit@debbugs.gnu.org; Sat, 28 Nov 2015 05:26:21 -0500 Received: from mout.gmx.net ([212.227.17.21]:49603) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2chu-0000D5-PD for 22009@debbugs.gnu.org; Sat, 28 Nov 2015 05:26:19 -0500 Received: from [192.168.1.100] ([213.162.68.93]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MFPyK-1a8B9u2nES-00EL76; Sat, 28 Nov 2015 11:26:14 +0100 Message-ID: <5659813D.1070509@gmx.at> Date: Sat, 28 Nov 2015 11:26:05 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' 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> In-Reply-To: <83oaefqi72.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:2E56cVZx3nCBOTd1PGK/xB/gb2WmTCivTiJO7HLeIo+87i+l7SH bjARSEDdhUbwe3boV/ZNUvqAGvuiHOp6vvbKL89UtVsEZ/msH809NYwPfBTo3e58Zuw+XZ0 7t2bU0UmMZYyMnFevQ2nEKOXs4O4LS/UPTCvybm1tm307KpPBe7cnswPtfm9uzSXOpdtr+h 4Pt6CbqnAeGJm0oGLlF9g== X-UI-Out-Filterresults: notjunk:1;V01:K0:KTibs5+Y21o=:q6T+JMwyF263hq1dOPVszK 5e+HdCcEt3UcK8Vk757/CmHbIqtoutn2fZfX7VskW8g5hlNb/HgBNh5jOO+U+NczRmd8zDlke 07vHlTELNeEU96zLr4Xv8KhSAJbmYlUEpXnV387MZ7dIh9zvNIWfS3jDQ9F/2DZkCAI7ogciW VdaiA7/pTN7csZY6rP9IN240mPzmCC3Pui2iSeJVZDtO+U3W9TxjMvc7qmn53AEBPHlhtQtwg ItnriyBu/6A8ZXXM8bA20Qw+xXpCFCd/62B3a3PxYlZhdXBcHqPHH+MWUkMCOY7mt0UC5JVRe Kq/1v69Ii6ZBCagDLXeHhCsJjE4IgoAQly7wj9sb/pKqcblT9yNQBZZXtstQqZ4d6wfetccgq sejXJNaVbDggbJXS26PBaxCBzn0gLc2zTp25YW8yJxfTPQuU8MbrTIqmf5sVA7qTuQ4c3Qmy2 2FRSLNfgbBJfSGrGevFT9jWzROjb1DurCOx4HQ3SHy9vaqtSx0q/VfuQMVJaKDeL8rR3EQo0Y OE0woRRz40KFolVtuC3q5lCEkorDojCmvMxjxt8kozjWApAGiHMMISRd5Ls98RuqqX624bWRk fKIqD5JXgVe6J9lZ7+GJ39AyuFJKPCYeoGbWNtnyLyFnQqjjf4Sn/RLgmohP+yDLX5i9CWB3t /OpV5TOf0Yw/UijNuSEuukvtRvpVC6waI6tBeOeGwp2ArmrmmOjm9ogV5qPkyF/59Itc3SDvd rLAC9FN9c8HRI6JoUtE2MZFiV1s62pAp34hfjDgf23Gz3X9nXbTML6TOstNanuMe/lxE/zWfQ Wn4QaYeE8RtV6NtWScVz7rsr0Q2bw== X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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. [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.93 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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. [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.93 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > 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 as you can derive from the following dialogue in a different thread. I said that > As I tried to explain before: =E2=80=98window-splittable-p=E2=80=99 is= hardly the > function we care about here. We care about =E2=80=98split-window=E2=80= =99 itself. and Joost answered > 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. So your question > So why > should we do anything about window-splittable-p if it only affects > functions that are not relevant to Joost's use case? should be answered now. Correct? > Hence my question: if we aren't fixing Joost's use case, and > display-buffer is not relevant to splitting windows with large > margins, what problem we are trying to solve with that patch? Joost's use case with making a window on the right of an existing one to show a buffer for `display-buffer'. > More importantly, if there isn't a clear-cut use case that will allow > us to decide which is the correct behavior, how can we decide whether > to make this change on master or on the release branch? And why did > you feel it was so important to fix it on the branch? What's the > urgency? If the fix is wrong it will be wrong for master too. And if I don't fix the code for the release branch but do care about the correctness of our docs, I have to rewrite doc-strings and Elisp reference in order to describe the inconsistency between vertical and horizontal splitting for the release branch. This is a bug I could ignore for some time simply by not looking at the code more deeply. Once I look at the code and see what it does, I have to react either by correcting the code or by changing the documentation. Anything else would be irresponsible. >> > Didn't you just tell they are called by display-buffer? How's th= at >> > "user territory"? >> >> The option =E2=80=98split-window-preferred-function=E2=80=99 is by de= fault set to >> =E2=80=98split-window-sensibly=E2=80=99. It's exclusively in the han= d of the user to >> change that. A mode that wants to change whether and how >> =E2=80=98display-buffer=E2=80=99 is supposed to split a window should= specify its own >> buffer display action in the call to =E2=80=98display-buffer=E2=80=99= =2E > > OK, and I'm still asking: how is all that related to > window-splittable-p? When we talk about that function, what is the > relevance of the user's ability to replace it to the discussion? If it is not related then I missed again what you were asking. I tried to guess twice but am apparently too silly to grok it. >> It would be more correct to rename >> >> =E2=80=98split-window-preferred-function=E2=80=99 -> =E2=80=98display= -buffer-split-window-preferred-function=E2=80=99 >> >> =E2=80=98split-window-sensibly=E2=80=99 -> =E2=80=98display-buffer-sp= lit-window-sensibly=E2=80=99 >> >> =E2=80=98window-splittable-p=E2=80=99 -> =E2=80=98display-buffer-wind= ow-splittable-p=E2=80=99 >> >> in order to avoid the misunderstandings we have here. > > And how is this renaming relevant to the patch that is being > discussed? 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. > 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 =E2=80=98(n)linum-mode=E2=80=99 which started to use margins for displayi= ng 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 =E2=80=98(n)linum-m= ode=E2=80=99 when deciding on the size of the margins. This is part of other threads, so I won't describe it here. 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, =E2=80=98split-window-right=E2=80=99= 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 =E2=80=98mouse-drag-vertical-l= ine=E2=80=99, 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 =E2=80=98display-bu= ffer=E2=80=99, =E2=80=98split-window-sensibly=E2=80=99 may refuse to split the wind= ow 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). martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 28 09:50:33 2015 Received: (at 22009) by debbugs.gnu.org; 28 Nov 2015 14:50:33 +0000 Received: from localhost ([127.0.0.1]:57657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2gpc-0007vL-58 for submit@debbugs.gnu.org; Sat, 28 Nov 2015 09:50:32 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:53735) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2gpF-0007ur-9D for 22009@debbugs.gnu.org; Sat, 28 Nov 2015 09:50:28 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NYJ002004HN4G00@a-mtaout20.012.net.il> for 22009@debbugs.gnu.org; Sat, 28 Nov 2015 16:50:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYJ001JF57IOJ90@a-mtaout20.012.net.il>; Sat, 28 Nov 2015 16:50:06 +0200 (IST) Date: Sat, 28 Nov 2015 16:49:56 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <5659813D.1070509@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83io4mp4a3.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Sat, 28 Nov 2015 11:26:05 +0100 > From: martin rudalics > CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org > > > 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 as you can > derive from the following dialogue in a different thread. I said that > > > As I tried to explain before: ‘window-splittable-p’ is hardly the > > function we care about here. We care about ‘split-window’ itself. > > and Joost answered > > > 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. > > So your question > > > So why > > should we do anything about window-splittable-p if it only affects > > functions that are not relevant to Joost's use case? > > should be answered now. Correct? Yes, thanks. But that still doesn't suggest how to fix window-splittable-p, unless we care _only_ for Joost's use case. And I don't think we can declare that only such use cases matter, as window-splittable-p is too general-purpose for that. > > More importantly, if there isn't a clear-cut use case that will allow > > us to decide which is the correct behavior, how can we decide whether > > to make this change on master or on the release branch? And why did > > you feel it was so important to fix it on the branch? What's the > > urgency? > > If the fix is wrong it will be wrong for master too. And if I don't fix > the code for the release branch but do care about the correctness of our > docs, I have to rewrite doc-strings and Elisp reference in order to > describe the inconsistency between vertical and horizontal splitting for > the release branch. This is a bug I could ignore for some time simply > by not looking at the code more deeply. Once I look at the code and see > what it does, I have to react either by correcting the code or by > changing the documentation. Anything else would be irresponsible. We agree that the code should be fixed. We just disagree about (or don't know) _how_ to fix it. > >> > Didn't you just tell they are called by display-buffer? How's that > >> > "user territory"? > >> > >> The option ‘split-window-preferred-function’ is by default set to > >> ‘split-window-sensibly’. It's exclusively in the hand of the user to > >> change that. A mode that wants to change whether and how > >> ‘display-buffer’ is supposed to split a window should specify its own > >> buffer display action in the call to ‘display-buffer’. > > > > OK, and I'm still asking: how is all that related to > > window-splittable-p? When we talk about that function, what is the > > relevance of the user's ability to replace it to the discussion? > > If it is not related then I missed again what you were asking. I tried > to guess twice but am apparently too silly to grok it. Forget it, it isn't related to the issue, so there's no need to explore this further. > (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). Agreed. And I don't think we can fix this only for that use case. We should try to look for a more general solution. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 28 10:49:21 2015 Received: (at 22009) by debbugs.gnu.org; 28 Nov 2015 15:49:21 +0000 Received: from localhost ([127.0.0.1]:58296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2hkW-0000vl-Jg for submit@debbugs.gnu.org; Sat, 28 Nov 2015 10:49:20 -0500 Received: from mout.gmx.net ([212.227.17.20]:64636) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2hkU-0000vd-Pm for 22009@debbugs.gnu.org; Sat, 28 Nov 2015 10:49:19 -0500 Received: from [192.168.1.100] ([213.162.68.93]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8e5P-1aFzZJ3WtP-00wGud; Sat, 28 Nov 2015 16:49:14 +0100 Message-ID: <5659CCF0.9020900@gmx.at> Date: Sat, 28 Nov 2015 16:49:04 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' 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> <83io4mp4a3.fsf@gnu.org> In-Reply-To: <83io4mp4a3.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:QLsz4/YeRLmf3+DmtZH/cjgNPwwVGKTS6c5s7eBrxDZ7YYgJhH+ NY4pi/+CKHJsCzZyB0gcv1LtG55Zlzv69byF5XLDDp8r2d0rRVc6O2ZhRNAd11S4dfaoKzg ly13EveAwDRIITlb+uRJPSN7tVejdXCUWrFtARdJKyOkTfwJk8e3NWQXIZ6u6SuCv+G97+P gwYFkBVrACwSqr5tOAG1w== X-UI-Out-Filterresults: notjunk:1;V01:K0:CRseBV40bBY=:SX9qUT8ZlLR/qBlAx4oN46 JDnV2Lbl3wF29OO5y9HHUSMrH1mP0OXW08qwClVWE2EnLDpa2QgIkJrQk0ttpxDsym62w3Zeg y9krX1MiY5RSGuR7t1mkXcizuZqeciEakAg4CHDFQtJJKOAg2K7LDMUPM7akP346TGRHqTd3t 7Rk0ToLJwGkv4T4EJOYLQ411GtGhCol6iWyQiFjfcYZ9tPHLCEK9RRLAVTk1eShvbP3lBSIyg j75hUP5LNhRnB7HRFV9bPG8pH0T/AHkbsSD/N+D6it4kvpLADKn6IJeQibg8mmooCNTt4OUX8 9hcfyw1aeDo/qUukHhJm9qQ5nXq72uYwD4TJSs8HViMS3qJDGRE2+XJ8E2T5N+JAOtmeQGrDU RyFC8Evimk+6VVz6d1vZEgduhVNKo6l9mFrtcdefdLgeg3C2/fsiEkAQ37U2oRczkJpOteEIC zQujz0QPadlu3C0F9smacDE4+AnMgAkfJhiEhSYvzt5pPKHaQHlkCioSGTD51Ah1LtYIEZz5X umldE9nhsPzHKJNMpEzvd3OJr7+IwBdML08yiONRNZk3AO/GQ78CHAUwqJEipjhM+s7RR6w7E 8xqYZER576GZLonb59K8yqPkbGWYMcgW5CAmlBi0wFrYPTrvLVb3JNS0OSd6RwaWExUf5oRLg 2wJsx6wSd48K1IYG5dQ0d7xU7R99+roQC8StecLx9CGZ54irJRSLFs6m1pjGhV/612WfjeirG uzFSHkfsEvJKkEj/lj0t05yvDesqaRt6KIMe2HpmZkYqXDS8pWzCY6tllCTM7kRFmroixl5Ni 4Q+qyEAt35oDcVZqrTTlMTGPOudXg== X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Yes, thanks. But that still doesn't suggest how to fix > window-splittable-p, unless we care _only_ for Joost's use case. And > I don't think we can declare that only such use cases matter, as > window-splittable-p is too general-purpose for that. [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.93 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] X-Debbugs-Envelope-To: 22009 Cc: joostkremers@fastmail.fm, 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Yes, thanks. But that still doesn't suggest how to fix > window-splittable-p, unless we care _only_ for Joost's use case. And > I don't think we can declare that only such use cases matter, as > window-splittable-p is too general-purpose for that. [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.93 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > Yes, thanks. But that still doesn't suggest how to fix > window-splittable-p, unless we care _only_ for Joost's use case. And > I don't think we can declare that only such use cases matter, as > window-splittable-p is too general-purpose for that. Indeed. Joost's fix also takes care of fringes, scroll bars and dividers. > We agree that the code should be fixed. We just disagree about (or > don't know) _how_ to fix it. If we do not fix the code on the release branch I have to fix a couple of doc-strings there telling that for historical reasons we do compare apples and oranges. Affected are =E2=80=98window-splittable-p=E2=80=99, =E2=80=98split-window-sensibly=E2=80=99 and =E2=80=98split-width-threshol= d=E2=80=99. For the latter two I'd have to amend the Elisp manual as well. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 07:47:39 2015 Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 12:47:39 +0000 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 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 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) 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 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) 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> User-agent: mu4e 0.9.13; emacs 24.5.50.1 From: Joost Kremers To: martin rudalics Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <5659813D.1070509@gmx.at> Date: Tue, 01 Dec 2015 13:47:29 +0100 Message-ID: <87egf6z672.fsf@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 Cc: Eli Zaretskii , 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 07:59:43 2015 Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 12:59:43 +0000 Received: from localhost ([127.0.0.1]:33848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3kX1-0005vC-DM for submit@debbugs.gnu.org; Tue, 01 Dec 2015 07:59:43 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56962) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3kWz-0005v4-Aa for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 07:59:41 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B114120FA9 for <22009@debbugs.gnu.org>; Tue, 1 Dec 2015 07:59:39 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 01 Dec 2015 07:59:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Lt53v WfC0mtlNOV2zvq4SsB3l3g=; b=K5GyRwvmRtDC5mKtv4FavqpvBeIU4WYinvRUq v9+ki+zhTfAuONWfLe3E4T5vJ0/c2aSDL7TTgIEuLpGODX/3a7Qe0e8FmgK8UMWJ I65Vhz0RGmXJjHVIA3h1QxrvLugkL/HPDSRc7JNyhTZ8Lwe3C2ku9bPqLHZJfFOA Yza9yk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Lt53vWfC0mtlNOV2zvq4SsB3l3g=; b=T9u59 dkowB4n7awJRVcvIYJyXSJUdl60YCwP9TuwA6qhOUVyDckG1v5rqXMaWTgKTAeHE qR0PzeePQSSda6x5LHBqLdPphPpVoJ1Hb4cGoM3MdFZhYQ7WOwfITxlHegVz2wpH jpPKaBps4z1Nfva5w5DBwNsnFxXwOX+3OeXrtc= X-Sasl-enc: /hb00974c8+MpH5Cyliy4jVKzNNBjNgE57IaiXKz3PNv 1448974779 Received: from IdeaPad.messagingengine.com (eruc065.goemobile.de [134.76.38.65]) by mail.messagingengine.com (Postfix) with ESMTPA id F1268C016F3; Tue, 1 Dec 2015 07:59:38 -0500 (EST) References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> <83mvtzqhz5.fsf@gnu.org> User-agent: mu4e 0.9.13; emacs 24.5.50.1 From: Joost Kremers To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <83mvtzqhz5.fsf@gnu.org> Date: Tue, 01 Dec 2015 13:59:36 +0100 Message-ID: <87d1uqz5mv.fsf@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Fr, Nov 27 2015, Eli Zaretskii wrote: >> From: Joost Kremers >> Date: Fri, 27 Nov 2015 02:16:22 +0100 >> >> The problem I'd like to solve (and the reason I submitted the patch) is >> that if a window has wide margins that are used to center the text, >> `window-splittable-p' will say that the window cannot be split >> horizontally, even though it can, because the margins are disposable. >> >> But actually, that's not the real problem. The real problem is that >> `window-splittable-p' simply has too little information to make an >> informed decision. >> >> The point is that the margins may be used for two different kinds of >> purposes: >> >> (1) The margins can be used to display useful information, in which case >> they should be retained when the window is split. >> >> (2) The margins can be used to reduce the width of the text area. In >> this case, the margins are disposable. > > There's one more factor here: whether the margins will remain at their > width after splitting. Yes, that is the actual issue. The point is that the way the margins are used determines whether they must remain at their width after splitting or not. > The mode which you presented and where the > current behavior was a problem changed the margins width as result of > the split (AFAIU), Yes, you understand correctly. > which is something the split decision cannot > possibly know. As things stand, no. > So I don't see how we could solve the problem even in > principle if we want to handle such modes correctly. By keeping track of which modes set the margins and whether they can be reduced in case of a window split or not, as discussed in the thread on emacs-devel. > The only way is > to ask the modes themselves, or provide a hook for them to override > the decision. I'm not sure that would be able to handle cases where different modes use the margins for different purposes. -- Joost Kremers Life has its moments From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 09:12:12 2015 Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 14:12:12 +0000 Received: from localhost ([127.0.0.1]:33898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3lf9-0007iF-Vk for submit@debbugs.gnu.org; Tue, 01 Dec 2015 09:12:12 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:41057) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3leo-0007hV-Sx for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 09:12:10 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1F67720D9D for <22009@debbugs.gnu.org>; Tue, 1 Dec 2015 09:11:50 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 01 Dec 2015 09:11:50 -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=iLgbC37LiNY+X31zDoT3SH6bnDM=; b=L6Wm7K wVEbS/qPx8gRnhmzdGrePTDvxWPILx2nEkvDa09K/fsaeaeLF09+UB5EtDwPKAHK 2eG0B9EkdUivrHmKYOLyyB3dJXtZgS2mgp/zEva74rLiDMp8NoflG10NZGH2FXjM r7pW+EXkvgJblWm/hD9IngKbqU2TLKApOcsZw= 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=iLgbC37LiNY+X31 zDoT3SH6bnDM=; b=NwVegQ8R+wHJPNMsbwQYMYhV/td2jq7w7SV5tKGtSxqWp1a 9g3j7ZqYQKfTuqB8hCfqRwJKyk87AZ8oCROGIBd5vR1Wa8LJ9BIYTRe6Claz+nA3 sNXH5LBP9MZK9Sn4ylgi7CzmXyqqhKQ+f9exGqaciVHPBfmcNwm6/aYX//5s= X-Sasl-enc: onwGYKarLqorUpOvqr+1NR9twrMXBN5pRAY9zzyloTNV 1448979109 Received: from IdeaPad.messagingengine.com (eruc065.goemobile.de [134.76.38.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B9FDC0001C; Tue, 1 Dec 2015 09:11:49 -0500 (EST) References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> <56581423.6010607@gmx.at> User-agent: mu4e 0.9.13; emacs 24.5.50.1 From: Joost Kremers To: martin rudalics Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <56581423.6010607@gmx.at> Date: Tue, 01 Dec 2015 15:11:48 +0100 Message-ID: <87bnaaz2aj.fsf@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Fr, Nov 27 2015, martin rudalics wrote: > > The point is that the margins may be used for two different kinds of > > purposes: > > > > (1) The margins can be used to display useful information, in which case > > they should be retained when the window is split. > > But ‘window-splittable-p’ is used in a context where usually we use the > new window to display another buffer than that of the original window. > To my knowledge nobody wants *help* or *completions* buffers to display > line numbers. But I'm talking about the original window, which is now narrower than it was before. If linum-mode is active in that buffer, it will still be active after the split and the window will need margins to accommodate the line numbers. > And if the original window has no margins but the new > window should display them, the current code won't help either. No, but the buffer displayed in the new window has a local value for `window-configuration-change-hook', which should take care of setting the margins (as it does in writeroom-mode). > > (2) The margins can be used to reduce the width of the text area. In > > this case, the margins are disposable. > > Let's specify the reason more explicitly: The margins are used to center > the text area in the window. Correct? Not necessarily, it's also possible that only one of the margins is widened. That is what visual-fill-column-mode does, another mode I wrote that mimics the effect of `fill-column' in buffers that use visual-line-mode. > > The only way to deal with both (1) and (2) correctly, and also with the > > case where different modes use the margins for (1) and (2) *at the same > > time*, would be to store information about the modes that use the > > margins and for which purpose. Then `window-splittable-p' could tell > > which part of the margins must be retained and which part is disposable. > > It would have to be clairvoyant wrt which kind of margins the buffer > displayed in the new window will have. ‘find-file’ can enable > ‘linum-mode’ in ‘find-file-hook’ but the real width of the margin needed > to display them will be known only when ‘linum-mode’ calculates it, that > is, _not_ at the time of splitting. Yes, of course, there's nothing to be done about that. `split-width-threshold' and/or `window-min-width' should be set up in such a way that the new window can comfortably display a buffer that has the margins that the user wants. But that's the user's responsibility. I'm only worried about the original window. Perhaps some clarification with screen shots is in order. Consider the following: http://wwwuser.gwdg.de/~jkremer/visual-fill-column1.png This is a buffer with a soft-wrapped text, with the right margin set to some large value so that the text is wrapped at `fill-column'. If I do `C-h f ' in such a window configuration, I get this: http://wwwuser.gwdg.de/~jkremer/visual-fill-column2.png which is odd, because there is so much "empty" space on the right. By using `window-total-width' in `window-splittable-p', I get this: http://wwwuser.gwdg.de/~jkremer/visual-fill-column3.png Much nicer, IMHO. (I'm not trying to defind my fix here, I know it's flawed. Just demonstrating what my use case is.) -- Joost Kremers Life has its moments From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 10:46:46 2015 Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 15:46:47 +0000 Received: from localhost ([127.0.0.1]:35223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3n8g-0001tA-JE for submit@debbugs.gnu.org; Tue, 01 Dec 2015 10:46:46 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:60842) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3n8e-0001t0-1W for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 10:46:44 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NYO00C00RPH0L00@mtaout26.012.net.il> for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 17:47:02 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYO00BIURUE2410@mtaout26.012.net.il>; Tue, 01 Dec 2015 17:47:02 +0200 (IST) Date: Tue, 01 Dec 2015 17:44:17 +0200 From: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <87d1uqz5mv.fsf@fastmail.fm> X-012-Sender: halo1@inter.net.il To: Joost Kremers Message-id: <838u5ekwby.fsf@gnu.org> References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> <83mvtzqhz5.fsf@gnu.org> <87d1uqz5mv.fsf@fastmail.fm> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > From: Joost Kremers > Cc: 22009@debbugs.gnu.org > Date: Tue, 01 Dec 2015 13:59:36 +0100 > > > The only way is > > to ask the modes themselves, or provide a hook for them to override > > the decision. > > I'm not sure that would be able to handle cases where different modes > use the margins for different purposes. I think this is the actual challenge in this bug report: design a way that would make it possible. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 01 12:31:11 2015 Received: (at 22009) by debbugs.gnu.org; 1 Dec 2015 17:31:11 +0000 Received: from localhost ([127.0.0.1]:35293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3olj-0004Ln-0Z for submit@debbugs.gnu.org; Tue, 01 Dec 2015 12:31:11 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:53662) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3olg-0004Lf-Oo for 22009@debbugs.gnu.org; Tue, 01 Dec 2015 12:31:09 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 466A120973 for <22009@debbugs.gnu.org>; Tue, 1 Dec 2015 12:31:08 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 01 Dec 2015 12:31:08 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=xttLp wOB+Q6QrqvaRZL7MJT0UBQ=; b=PqJM7JiM9xuCMOSMbrnAmZBefyXRvDMUv06vP FSo4iv/kAtNxqVL/lGP1+C/lOblHAUD+mQtb80WmT/7hVbWy6/+SaTfEGaCackEf 9ixVidbiCJrW58m9N/2uMCNxjzictqcz7/QQPFth4pNAkKUg8bAf1z/4TnpIS4pc fC+WTU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=xttLpwOB+Q6QrqvaRZL7MJT0UBQ=; b=i+a9x RH6dBo4XY5nk3j2Pjqm5cNHQYMUUJf+GOhrQXsE5kI61CiynMnDL27/bjidsTpnr nWVk/2Jc3Dzizkg1EsBT46acFxr8rkePRMjMFolmGq4ECpPkJvktoaUM2gsPFdX1 9qMnY8sRMlXvuE+R7Bqc7QNAV3bTvbjfulrPdk= X-Sasl-enc: 3TcvRAoUTqmkjcaPmMmFxX+lamsS+PymdHcCRCStfoET 1448991067 Received: from eeenterprise.messagingengine.com (p5b0fb5c7.dip0.t-ipconnect.de [91.15.181.199]) by mail.messagingengine.com (Postfix) with ESMTPA id 876CFC016C4; Tue, 1 Dec 2015 12:31:07 -0500 (EST) References: <87io4qgrcg.fsf@fastmail.fm> <87lh9kw8bd.fsf@fastmail.fm> <83mvtzqhz5.fsf@gnu.org> <87d1uqz5mv.fsf@fastmail.fm> <838u5ekwby.fsf@gnu.org> User-agent: mu4e 0.9.15; emacs 24.5.2 From: Joost Kremers To: Eli Zaretskii Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <838u5ekwby.fsf@gnu.org> Date: Tue, 01 Dec 2015 18:31:00 +0100 Message-ID: <87610iuld7.fsf@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Dec 01 2015, Eli Zaretskii wrote: >> From: Joost Kremers >> Cc: 22009@debbugs.gnu.org >> Date: Tue, 01 Dec 2015 13:59:36 +0100 >> >> > The only way is >> > to ask the modes themselves, or provide a hook for them to override >> > the decision. >> >> I'm not sure that would be able to handle cases where different modes >> use the margins for different purposes. > > I think this is the actual challenge in this bug report: design a way > that would make it possible. Yes. We discussed a possible way of doing this in the thread on emacs-devel. I'll start a new thread there with a summary of the issues and a proposal on how to solve them. -- Joost Kremers Life has its moments From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 04 08:57:36 2017 Received: (at control) by debbugs.gnu.org; 4 Jun 2017 12:57:36 +0000 Received: from localhost ([127.0.0.1]:54735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHV68-0003fw-2g for submit@debbugs.gnu.org; Sun, 04 Jun 2017 08:57:36 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:38750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHV66-0003fj-2p for control@debbugs.gnu.org; Sun, 04 Jun 2017 08:57:34 -0400 Received: by mail-it0-f46.google.com with SMTP id r63so54683423itc.1 for ; Sun, 04 Jun 2017 05:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:mime-version; bh=N073Fl6Bwf8L1yM1sL9IHH/nnb+1fy4UsUjtyND5rnA=; b=SNAQmJCGK9KDxGzN5JYpNXHIc9MhqQRLl0kC1QRrBo7sHm7E54ZujGKEUSk1qSHOdh msjWtx2sdilBI7Q4uMQLsBEFhuwcoTg5Y6keYtbXpxYu7x9PrH0wAVcg4OHuckRG5ffd CpbdYMyXHM1mubtE1DUUHNRz8AP7ExSrBBEa6t1UzW9KvIuGd0gmkP6hXpb1A8zMLbGm S/9yoacffsQlNhrkkC1N9y0pgJ0tD1amjuCVsjVT0Fzc3RiMXo4RucBuhhdmSK3yxBUq LvRm0spd6Hpk9e7+lghEMnSznuazSIQz93ZWRlsKEQX16aZe+MVykuc8x/UuIrntuzht HfMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version; bh=N073Fl6Bwf8L1yM1sL9IHH/nnb+1fy4UsUjtyND5rnA=; b=drQnrZPWgc0iPucRxNqJRostfJa6JuEWHZnPu9cQEkdEKRWGw7FEAuhdBgmGyZlgch X2KOR503HQYVI/8dlkNinCdbm3+uhxsg6ILdTmBZn5jB571Fm8rlCLLhHJQq3Wy+gbAd QbePSKMocnwQn6NK76TVUsFjApw3MjN+xb3pz13j+C4NdfpulrRdHPDE2PZVE/pXJRPA 9L9zutL1tPC1BIycWteZW9zq1rQCBhoNLdnLckazZB42YSvz5k1M8/qEvQ6AHNeF9d0o BDhVkwAVpWTanVbL8ICWALBUOPAHD8XWsYvJiL5WvDDqjWj2hab6FZK0eUkcfKZkUw6Q 8B1g== X-Gm-Message-State: AODbwcCb06wPE+Od05I3gttKqTBFTao4kui+8o223WTGVZomA64NvQ2c vCZUCPAetDhQzKzI X-Received: by 10.107.11.137 with SMTP id 9mr15388324iol.86.1496581048217; Sun, 04 Jun 2017 05:57:28 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id b24sm129534iod.33.2017.06.04.05.57.26 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 04 Jun 2017 05:57:27 -0700 (PDT) From: npostavs@users.sourceforge.net To: control@debbugs.gnu.org Subject: control message for bug #22009 Date: Sun, 04 Jun 2017 08:59:05 -0400 Message-ID: <87o9u3zz6u.fsf@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) retitle 22009 Inconsistent handling of window splitting with margins quit From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 07 12:48:26 2020 Received: (at 22009) by debbugs.gnu.org; 7 Sep 2020 16:48:26 +0000 Received: from localhost ([127.0.0.1]:50638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFKJe-0005hj-2o for submit@debbugs.gnu.org; Mon, 07 Sep 2020 12:48:26 -0400 Received: from quimby.gnus.org ([95.216.78.240]:59450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFKJb-0005hO-JZ for 22009@debbugs.gnu.org; Mon, 07 Sep 2020 12:48:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HqY3ASYfNQcf3+5iJh2JrakNRg2/Yrmg0nD3FPTBljQ=; b=uHtAXpQCEkLV4AhtC9tEUiE28q afxkd8d8aIJK/kbN+i2qZUE9pTqIv29HOaGG3JW3dw9ozFynAR1ZcVvLlQk+QJh782ewvpKLEsxTc is3sDgAquvy0l+0LfRMeuWyQ47ItTVRCdKLDNc5wJ0MmJ1ethyWjLB/RlZmfTX6yvHn4=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFKJS-0001R7-N1; Mon, 07 Sep 2020 18:48:17 +0200 From: Lars Ingebrigtsen To: Joost Kremers Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' References: <87io4qgrcg.fsf@fastmail.fm> X-Now-Playing: Coil's _A Prison of Measured Time_: =?utf-8?Q?=22Heaven?= =?utf-8?Q?=E2=80=99s?= Blade (Dark Night Mix)" Date: Mon, 07 Sep 2020 18:48:13 +0200 In-Reply-To: <87io4qgrcg.fsf@fastmail.fm> (Joost Kremers's message of "Wed, 25 Nov 2015 14:07:27 +0100") Message-ID: <87eend5y9e.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Joost Kremers writes: > Following discussion on emacs-devel (thread "Window splitting issues > with margins"), this patch replaces the call to `window-width' in > `window-splittable-p' with `window-total-width'. This takes [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Joost Kremers writes: > Following discussion on emacs-devel (thread "Window splitting issues > with margins"), this patch replaces the call to `window-width' in > `window-splittable-p' with `window-total-width'. This takes the window > margins into account when determining if a window can be split > horizontally. [...] > - (>= (window-width window) > + (>= (window-total-width window) [...] >>> I'm not sure that would be able to handle cases where different modes >>> use the margins for different purposes. >> >> I think this is the actual challenge in this bug report: design a way >> that would make it possible. > > Yes. We discussed a possible way of doing this in the thread on > emacs-devel. I'll start a new thread there with a summary of the issues > and a proposal on how to solve them. Skimming this bug report, I think everybody pretty much agreed that this patch was better than the current behaviour, but that this new behaviour isn't completely correct (especially for those mode that use the margins to display useful information). Did the discussion on emacs-devel come to any sort of useful conclusion? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 04:51:00 2020 Received: (at 22009) by debbugs.gnu.org; 8 Sep 2020 08:51:00 +0000 Received: from localhost ([127.0.0.1]:51880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFZLA-0004po-Iz for submit@debbugs.gnu.org; Tue, 08 Sep 2020 04:51:00 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:38017) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFZL7-0004pa-V9 for 22009@debbugs.gnu.org; Tue, 08 Sep 2020 04:50:58 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 96EC75C01C6; Tue, 8 Sep 2020 04:50:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 08 Sep 2020 04:50:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= references:from:to:cc:subject:in-reply-to:message-id:date :mime-version:content-type; s=fm1; bh=1jjkyvlx/2toyBJNdUphnWDxV7 WYaoT6xlyi3jbYitA=; b=FOmD3lkAHp1oKj81L9ZeQISHNJQRbK84sCCuDb1+fT VCi5UxB/Xk/yexLIzUTt3v+LAFyuIi6wY412Rew7LniOerhONNAPiyoTo408kzUb InfSffGeiAiIGCr2ymQu55vFd6uLiyVl6DuK7hr16IElL4tJ+0asAm/Y0EbjyxOC UshDOMcPE6nmStQMascISa6GQU/3KL80EUIEwGB82mIUgBDQdf8bzZYeUjQkwI3f OCE5CplY5YI7GxZMy5sOsJ+JNMM3DxJHyid60djVpH2xXAdnKkMiDCf5WMz31bIT 1n2saVu/8+9peErKmBxhbN5/01+uVTlVwacGk59Lm7Fg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=1jjkyv lx/2toyBJNdUphnWDxV7WYaoT6xlyi3jbYitA=; b=m5wgtdYZZ56fAolLsgVD6m 2F2JafVb9q6Nv5BSbT1uccquKbDbkrfB11x3vE4WyK+0MyW01QPV5gkMhVSFxBG9 dogHmBrA8VSQnQb+22wZczzsqovK9C9xPFrM9jfouWNPZ5e8xZ982i0l/w61bxL0 jmqviWeGLuCgQ/vvPnrih6EWO53C3ydGr+Sb7kfDh5w6LOQtp9n9JnT0OV06ZYJr dVjyLgZkKKXyeXj4Hd9BU3W+bpBLZ8cLIT1eCtjISZHYRhklDbjolByBAtG9YHs3 +Scs4gSqM8A3MVGJ2H8W08WsUbbMaNfVdv06Mp8AV2q1EAQVA+gHdS/BsgrZEhgQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehvddgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfhgfhffvufgjkfffgggtsehttdertddtredtnecuhfhrohhmpeflohhoshht ucfmrhgvmhgvrhhsuceojhhoohhsthhkrhgvmhgvrhhssehfrghsthhmrghilhdrfhhmqe enucggtffrrghtthgvrhhnpeettdejvdehiedtffekgeffvefhuefffedtjeetudelgffh feevgeelkeefvdetjeenucfkphepleehrdeltddrvddvgedrvdegheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhoshhtkhhrvghmvghr shesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: from Swift.fastmail.com (ip5f5ae0f5.dynamic.kabel-deutschland.de [95.90.224.245]) by mail.messagingengine.com (Postfix) with ESMTPA id 9627A3280063; Tue, 8 Sep 2020 04:50:51 -0400 (EDT) References: <87io4qgrcg.fsf@fastmail.fm> <87eend5y9e.fsf@gnus.org> User-agent: mu4e 1.5.5; emacs 27.1.50 From: Joost Kremers To: Lars Ingebrigtsen Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' In-reply-to: <87eend5y9e.fsf@gnus.org> Message-ID: <87bligy7me.fsf@fastmail.fm> Date: Tue, 08 Sep 2020 10:50:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Mon, Sep 07 2020, Lars Ingebrigtsen wrote: > Joost Kremers writes: >>>> I'm not sure that would be able to handle cases where >>>> different modes >>>> use the margins for different purposes. >>> >>> I think this is the actual challenge in this bug report: >>> design a way >>> that would make it possible. >> >> Yes. We discussed a possible way of doing this in the thread on >> emacs-devel. I'll start a new thread there with a summary of >> the issues >> and a proposal on how to solve them. > > Skimming this bug report, I think everybody pretty much agreed > that this > patch was better than the current behaviour, but that this new > behaviour > isn't completely correct (especially for those mode that use the > margins > to display useful information). Yes, that summarises my memory of the discussion. > Did the discussion on emacs-devel come to any sort of useful > conclusion? I'd have to dig up those threads again to be sure, but from what I remember, the proposal that I made was deemed too complicated for the problem at hand (probably rightly so). In the end, the window parameter `min-margins' was added and IIRC some changes were made to the way `window-configuration-change-hook' and `window-size-change-functions' operate (I may be mistaken on the latter point, though). That didn't solve the problem of allowing multiple modes to use the margins without interfering with each other, but it should solve the original problem of splitting windows with large margins. I say "should", because at the time, I decided against using `min-margins' in my code (`visual-fill-column.el), so I never actually tested it. (My existing code still worked in Emacs 25 (and indeed in 27.1) and I didn't want to drop support for Emacs 24. It might be time to reconsider that decision, though, given that Emacs 25.1 is four years old now.) -- Joost Kremers Life has its moments From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 06:05:10 2020 Received: (at 22009) by debbugs.gnu.org; 8 Sep 2020 10:05:10 +0000 Received: from localhost ([127.0.0.1]:52051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFaUw-0000RG-7G for submit@debbugs.gnu.org; Tue, 08 Sep 2020 06:05:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFaUv-0000Qx-58 for 22009@debbugs.gnu.org; Tue, 08 Sep 2020 06:05:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zy+rLcgcTjWpByUXYPEBZ+BPHxudynKu2uupv4yMQQw=; b=mUP4b2ckp2ML8Jintk3hgPsTKN T/Wqx6MC1CQzaVY7ciSlEnSZt8FAjV8WXLnKF8dlatxSo2/gaUE6l5da1ojtS4e1MHBIMGIiNW7IJ 0yAGvYnoKaPubP8+bEPebSx7RCAo6kCOKhnLtO3ultjPp8SEuApyEVY3GML+MaYey5UQ=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFaUn-0001tA-0S; Tue, 08 Sep 2020 12:05:03 +0200 From: Lars Ingebrigtsen To: Joost Kremers Subject: Re: bug#22009: PATCH: Use `window-total-width' in `window-splittable-p' References: <87io4qgrcg.fsf@fastmail.fm> <87eend5y9e.fsf@gnus.org> <87bligy7me.fsf@fastmail.fm> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX3sTnAYxLp2KFd PBv69+D///9kZhvsAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+QJCAoAOds3tHQAAAG6SURBVDjLdZTr keQwCIQlrQMQ5wQ0DAl4nMCWlvxj2m4kax53px+uMp9pQcNMSlXjpMJnK/PtK+GoedcEkl7PeVR+ PN+y1AVIUptvIvIEQbK8g0JwHiL7GSIfIA5D+V1qnIMxOf8D8r8y9mOGSnsDQCNS9G+gEeczv4HN EdMJoodZsLk3ZkBKUk2LSJh5AdqEtgiqey50O0B8UCNJLuMDsLSKxqYp18EdIhX1D7CGgaqgv3UA +QKQXEN+gOIoP0sDOHJaI66IBzAYiJFVdVaVE5oiSGJNaOPmPspdYGt5h66qcWVWRkYJY7DlBXQk S+mN9daivXA3CKyzTf9OzFDtHPGQYiPVGajFeDnKmAAraE5cOoTzuTLQAkxP6Jxz2ifQhrUBAKn0 A8ZBqrsqF43AEz3JSJAoIoCgZ2/Q4myEAPYs4OgFzoxN3aXwtQagO20uvwwwMi4Yd8EFahV/JeP4 B1jE2gX6IsGsB4BN2q0bcWwXjLsBdNX7Qx8/N/y+PYWc+XeAO3q73c8/SsApBdi6YREghkwDcFNK HVcfnX8UATim9mxQz8fjPgF8ewJTKC4gHw3iclsg6Sv4BcIggr7UaWxqAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIwLTA5LTA4VDEwOjAwOjU3KzAwOjAwsYS1/AAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy MC0wOS0wOFQxMDowMDo1NyswMDowMMDZDUAAAAAASUVORK5CYII= X-Now-Playing: Sleaford Mods's _Eton Alive_: "Kebab Spiders" Date: Tue, 08 Sep 2020 12:05:00 +0200 In-Reply-To: <87bligy7me.fsf@fastmail.fm> (Joost Kremers's message of "Tue, 08 Sep 2020 10:50:49 +0200") Message-ID: <87pn6w60tv.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Joost Kremers writes: > That didn't solve the problem of allowing multiple modes to use the > margins without interfering with each other, but it should solve the > original problem of splitting windows with large margins. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22009 Cc: 22009@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Joost Kremers writes: > That didn't solve the problem of allowing multiple modes to use the > margins without interfering with each other, but it should solve the > original problem of splitting windows with large margins. Oh, OK. Then I guess the reported bug here was fixed in a different manner, so I'm closing this bug report. It might be nice to allow modes to express something about their intentions with the margin, but I guess that's a separate issue. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 06:05:21 2020 Received: (at control) by debbugs.gnu.org; 8 Sep 2020 10:05:21 +0000 Received: from localhost ([127.0.0.1]:52054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFaV7-0000Rh-G1 for submit@debbugs.gnu.org; Tue, 08 Sep 2020 06:05:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFaV6-0000RS-5M for control@debbugs.gnu.org; Tue, 08 Sep 2020 06:05:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2FYExwOa2/8w48Udfr+ws9BhWlp7c7LMDhgqlK6iknk=; b=cEFEeng40q6S65Dp75ErYOR6tC lTyCf2B4MxdszeXE/vPDIFeqU+2Q3OAwk5KILkW63KjhGB4vUH+w0Bdeq7uwXZ5yrpdVcJzXCOjgP aJ9pUi4qkxDj3/YcfvY9OIu84Wk8uCpD85demjsmVtMKs/S4xBLAF6+qi5E/LfTpwxYc=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFaUy-0001tP-I8 for control@debbugs.gnu.org; Tue, 08 Sep 2020 12:05:14 +0200 Date: Tue, 08 Sep 2020 12:05:11 +0200 Message-Id: <87o8mg60tk.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #22009 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 22009 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 22009 quit From unknown Mon Jun 23 23:53:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 06 Oct 2020 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator