From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: PATCH: make linum.el play nicely with other margin-setting extensions Date: Fri, 13 Nov 2015 15:53:12 +0100 Message-ID: <5645F958.6040409@gmx.at> References: <5645B4F6.7000306@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447426436 3611 80.91.229.3 (13 Nov 2015 14:53:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 14:53:56 +0000 (UTC) Cc: markus.triska@gmx.at, emacs-devel@gnu.org To: =?windows-1252?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 15:53:42 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZxFjQ-0003HO-Ps for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 15:53:41 +0100 Original-Received: from localhost ([::1]:53453 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxFjL-0003ra-FH for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 09:53:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxFjD-0003rR-Ry for emacs-devel@gnu.org; Fri, 13 Nov 2015 09:53:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxFj8-00049X-Ri for emacs-devel@gnu.org; Fri, 13 Nov 2015 09:53:27 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:50415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxFj8-00049S-I5 for emacs-devel@gnu.org; Fri, 13 Nov 2015 09:53:22 -0500 Original-Received: from [192.168.1.100] ([213.162.68.112]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Md3ZK-1Zg8Y6379G-00IElO; Fri, 13 Nov 2015 15:53:20 +0100 In-Reply-To: X-Provags-ID: V03:K0:RXwn08NRDUgXhwoiXc55xBSF16qovXyBXAldOIQREHZAafG/3xy 0TvL3NoWdSnEnusWOyzClaXjA9gfl251sa76GnKuYmGDbXyFIhVbvWD0KvxyWN2Q8uP+DfF ckyNbdZkgjfu81cK0GplvTIv8KhXwe4xmTgGqaGmaYHFYAk2pfnDUADXvfYZyjhMZvRvz7w OY/RzhhNFz/zxIUNbuVhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:/yuZiSv7DaE=:rWlDM63QKNZ/TX8M8+hX/F V+/GNa793gRJcKsquxAOyoYX4XTGPfJqoedCvjkMTv7ncT7rjk+zICRJyzwE/PF/qYzDe9AlO QZmqYutvt3hc6PTLT4Ijc/pTktvWie9FqBzzWk3VzObgKOe92drNutSgrD5/Rdh/T67vIRZlF /80opNjbLanyybQfsjRTfTOb9ET323sDlcAI/V2Hrnxw0f/R1WxvhWzH9664lHQ7I8DJ/3Hh9 ZbqGh6HBGNEz9JKq9ZYsNrboOoatPRbDpA/hT465BhaVPmNpGAveNaTwqCCS7yw98hPPhW26d 6/3Ksc7wu948tFvUKU3ct73SA/VtNK3PkJV3bW6Z2BxouA80nTzJlKbB2cvdmzuiwwRAReZQu /2Zly1zEnfKgS2CaKqfjMkhTdNCRvrb5AHGIzITrYnltmlauQfffO9XjetVMC+Pcrm00c9iBc ch7q3t4EUJDqxOVpTZa4YkU87fdGgCcgo5YKtBh700BXMTeVQTZqvopNapbwadbSoEGSalBhu NVfE7lYs0dzVT/uF/iWoaF7hcZ973ZR5wZFXQ1pN6HLCC7W3ZcYEttqwBG3vtIpy5RiscrDwT k6s2GFX54pwmn4qpaZz0m+XNGTkHGuZ1X3qq9twkXM55eO6+K2XvhsvZ+0ZD8kjo7K3oeLLvH bqHZO4XaJDzSCi5GP75Pp0jMxHJSUy+EXKGdn+tSDPQDoiiEgo0ZB4cl3wrFLHRy/n0fTkD1t 9ATJhIjpgXFhSHe3xRxyRXnv/Moizf9ZC4+jcEHcr66t2IY1mAaXQ0fD/Ra5Tz1HcEW4rR8J X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194369 Archived-At: > Though if we come up with `left-margin-min-width' we'll probably have = to > come up with some `max-width' version some time in the future, no? And= > so on for every other window-related property. And so on for every > frame-related property while we're at it. I see no problems here. We can have each mode add its preferred margin settings as a triple with a minimum, preferred and maximum width for the left and right margins and some kind of priority. And do similar things for the text area, fringes, scrollbars and whatever we want. The greatest problem is to handle all these options. The parameter with the highest priority would specify the preferred size, the remaining ones constrain minimum and maximum. And all these constrained by the total size of the window/frame. > Woundn't it be nicer that a package/mode, when it so sees fit, could > mark a particular window|frame|buffer setting as being "owned" by it a= nd > then query arbitrarily later if it still owns it? But wasn't the problem that darkroom should respect the minimum width of =91linum-mode=92 and vice-versa? How would "owning" fit into this? > Clearly if *all* extensions played by these rules we would be out of t= he > woods: the test would become > > (if (eq (get-setting-owner 'set-window-margins w) 'linum) > ;; reset the margins to whatever was there before This "before" is problematic when a second or third mode kicks in after an owner has set its preferred size. > ;; else do nothing > ) And how do we decide prioritization when the "owner" is deactivated and there are two or more contenders? martin