From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: PATCH: make linum.el play nicely with other margin-setting extensions Date: Sat, 14 Nov 2015 10:53:09 +0200 Message-ID: <83k2pldksq.fsf@gnu.org> References: <83vb97i3ta.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1447494105 16948 80.91.229.3 (14 Nov 2015 09:41:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Nov 2015 09:41:45 +0000 (UTC) Cc: markus.triska@gmx.at, emacs-devel@gnu.org To: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 14 10:41:37 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 1ZxXKy-0008TU-C2 for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 10:41:36 +0100 Original-Received: from localhost ([::1]:33131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxXKx-00022F-3s for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 04:41:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxWaJ-000176-To for emacs-devel@gnu.org; Sat, 14 Nov 2015 03:53:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxWaG-0006c4-N4 for emacs-devel@gnu.org; Sat, 14 Nov 2015 03:53:23 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:51956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxWaG-0006bx-GH for emacs-devel@gnu.org; Sat, 14 Nov 2015 03:53:20 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NXS00K00R09J900@mtaout26.012.net.il> for emacs-devel@gnu.org; Sat, 14 Nov 2015 10:56:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXS00J24RI5YS20@mtaout26.012.net.il>; Sat, 14 Nov 2015 10:56:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:194444 Archived-At: > From: joaotavora@gmail.com (Jo=C3=A3o T=C3=A1vora) > Date: Fri, 13 Nov 2015 08:32:57 +0000 > Cc: markus.triska@gmx.at, emacs-devel@gnu.org >=20 > linum.el uses the left margin to make just enough to show numbered > indicators. The gist of this patch is: if there is enough space the= re > already, linum.el won't set the left margin width. >=20 > But if it does, it records that fact in a window parameter, to chec= k > later, when turning off linum-mode, if resetting the margin is > needed. In this situation, resetting the margin is only needed if > linum-mode was the only extension to touch it, otherwise one consid= ers > that some other extension or interactive "set-margins" call touched= the > margins. >=20 > The way I implemented "some other extension ... touched the margins= " is > an equal test of current margins vs remembered set margins. >=20 > It seems robust enough for now, but ideally linum-mode would know t= hat > "his" margins have been overriden interactively or by some other > extension, and decide in accordance. Thanks for the explanations. Could you please look at nlinum.el (in ELPA) and see whether its solution to this problem is better, or at least not worse, and satisfies the needs of darkroom-mode? If so, I'= d rather we adopted the nlinum solution in linum as well. If there's something to be done for coexistence with nlinum, I'd prefer to have a solution that works with both linum and nlinum. Thanks.