From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Nathan Trapuzzano Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Jan 2013 01:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 13446@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135821245810452 (code B ref -1); Tue, 15 Jan 2013 01:15:01 +0000 Received: (at submit) by debbugs.gnu.org; 15 Jan 2013 01:14:18 +0000 Received: from localhost ([127.0.0.1]:60515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tuv6X-0002iW-Jd for submit@debbugs.gnu.org; Mon, 14 Jan 2013 20:14:17 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38157) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tuv6U-0002iP-P3 for submit@debbugs.gnu.org; Mon, 14 Jan 2013 20:14:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tuv61-0006XQ-EY for submit@debbugs.gnu.org; Mon, 14 Jan 2013 20:13: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=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:38382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tuv61-0006XM-Bm for submit@debbugs.gnu.org; Mon, 14 Jan 2013 20:13:45 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tuv5y-0004P5-CD for bug-gnu-emacs@gnu.org; Mon, 14 Jan 2013 20:13:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tuv5v-0006Vp-PB for bug-gnu-emacs@gnu.org; Mon, 14 Jan 2013 20:13:42 -0500 Received: from oproxy9.bluehost.com ([69.89.24.6]:50056) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Tuv5v-0006VX-F2 for bug-gnu-emacs@gnu.org; Mon, 14 Jan 2013 20:13:39 -0500 Received: (qmail 5038 invoked by uid 0); 15 Jan 2013 01:13:15 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy9.bluehost.com with SMTP; 15 Jan 2013 01:13:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=cBCSS3ka0QN+ewZGbuqoYVtDUUlTEsf6A9aOidzyPwg=; b=UCzxdsuOfXTAbsYylAH3fNlYHWvm2SSHqijws6YUErCVXI3R0psqF/lo+v/5liUw9zxQP5onlEp0m0UVi4Vwf8f77ZIMsA2Wksl/KBMUrRVn1WTZVRjCsfHz9Q6NsonP; Received: from [76.240.203.247] (port=58418 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tuv5X-0004M7-8h for bug-gnu-emacs@gnu.org; Mon, 14 Jan 2013 18:13:15 -0700 From: Nathan Trapuzzano Date: Mon, 14 Jan 2013 20:13:13 -0500 Message-ID: <87y5fvp7ti.fsf@nbtrap.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 76.240.203.247 authed with nbtrap@nbtrap.com} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.7 (----) --=-=-= Content-Type: text/plain There is an incorrect loop test in linum.el that potentially applies an overlay to a line not visible in the window and thereby messes up the width of the overlays in the lines that are visible. The patch/merge directive is attached, and what follows is the commit message: ----- Modify loop test in `linum-update-window'. `limit' is set to the position returned by `window-end'; this position is either on the last visible (logical) line in the buffer or is the first position on the line following the last visible line. In the former case, the loop variable never reaches the value of `limit', but in the latter case, an overlay is applied to a line that is not visible in the window. This can mess up the width of the overlay on the visible lines, especially if the width of the line number (as a string) of the line that's not visible is different from the width of the visible lines' line numbers. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=linum.patch # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: nbtrap@nbtrap.com-20130115010121-h7kwjyr5kimowgml # target_branch: . # testament_sha1: a9154d3ede2b389220646bb8e9e708117d876d01 # timestamp: 2013-01-14 20:03:26 -0500 # base_revision_id: nbtrap@nbtrap.com-20130111013646-pn4xh5r94x5asomb # # Begin patch === modified file 'lisp/linum.el' --- lisp/linum.el 2012-01-19 07:21:25 +0000 +++ lisp/linum.el 2013-01-15 00:45:27 +0000 @@ -151,7 +151,7 @@ (run-hooks 'linum-before-numbering-hook) ;; Create an overlay (or reuse an existing one) for each ;; line visible in this window, if necessary. - (while (and (not (eobp)) (<= (point) limit)) + (while (and (not (eobp)) (< (point) limit)) (let* ((str (if fmt (propertize (format fmt line) 'face 'linum) (funcall linum-format line))) # Begin bundle IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdjgvvgAABJfgAAQQGFxUBIA AACv794QIABkRTaajamQyGjTaRiFGgBMBBkwQhDmaVnH5r9hMFQyJ7EUzThiw4Ixc/mQVpexbPS2 9yLLTxaFbWvXcN2zcydOQxpD652acQC4g4Z96jI5BipgKAAiM5Zz45Kd/4u5IpwoSGxwX3wA --=-=-=-- From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Nathan Trapuzzano Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Oct 2013 15:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 13446@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.13827148593690 (code B ref -1); Fri, 25 Oct 2013 15:28:02 +0000 Received: (at submit) by debbugs.gnu.org; 25 Oct 2013 15:27:39 +0000 Received: from localhost ([127.0.0.1]:43620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZjIX-0000xN-M9 for submit@debbugs.gnu.org; Fri, 25 Oct 2013 11:27:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51936) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZjIU-0000wt-Vy for submit@debbugs.gnu.org; Fri, 25 Oct 2013 11:27:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZjIH-0008TJ-Q5 for submit@debbugs.gnu.org; Fri, 25 Oct 2013 11:27:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZjIH-0008TA-MY for submit@debbugs.gnu.org; Fri, 25 Oct 2013 11:27:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZjIA-0003Os-NU for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:27:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZjI3-0008Qe-Oq for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:27:14 -0400 Received: from oproxy13-pub.mail.unifiedlayer.com ([69.89.16.30]:45978) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1VZjI3-0008QC-Fn for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 11:27:07 -0400 Received: (qmail 16461 invoked by uid 0); 25 Oct 2013 15:26:38 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy13.mail.unifiedlayer.com with SMTP; 25 Oct 2013 15:26:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:To:From; bh=lYQcpg/uS6tDl+J+0746jRBxAX+/V9Ugfn6eItLmfFg=; b=TGEv1LgbPy7wBnQFt8zuW+n4DbSGj5pc/5SIMfmxRCF7AgXOXzdI586YmtySHomjGNdPJ8hqHETx6vCGiG5Wu1bopGTld/Leld96BaJYSCeXYraHyJBGPLPxCqlZrEfF; Received: from [50.90.253.209] (port=41765 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1VZjHZ-00021s-85 for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 09:26:37 -0600 From: Nathan Trapuzzano References: <87y5fvp7ti.fsf@nbtrap.com> Date: Fri, 25 Oct 2013 11:26:32 -0400 In-Reply-To: <87y5fvp7ti.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Mon, 14 Jan 2013 20:13:13 -0500") Message-ID: <874n85cqxj.fsf@nbtrap.com> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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-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 (----) Any reason why this hasn't been accepted? Nathan Trapuzzano writes: > There is an incorrect loop test in linum.el that potentially applies an > overlay to a line not visible in the window and thereby messes up the > width of the overlays in the lines that are visible. The patch/merge > directive is attached, and what follows is the commit message: > > ----- > > Modify loop test in `linum-update-window'. > > `limit' is set to the position returned by `window-end'; this position > is either on the last visible (logical) line in the buffer or is the > first position on the line following the last visible line. In the > former case, the loop variable never reaches the value of `limit', but > in the latter case, an overlay is applied to a line that is not > visible in the window. This can mess up the width of the overlay on > the visible lines, especially if the width of the line number (as a > string) of the line that's not visible is different from the width of > the visible lines' line numbers. > # Bazaar merge directive format 2 (Bazaar 0.90) > # revision_id: nbtrap@nbtrap.com-20130115010121-h7kwjyr5kimowgml > # target_branch: . > # testament_sha1: a9154d3ede2b389220646bb8e9e708117d876d01 > # timestamp: 2013-01-14 20:03:26 -0500 > # base_revision_id: nbtrap@nbtrap.com-20130111013646-pn4xh5r94x5asomb > # > # Begin patch > === modified file 'lisp/linum.el' > --- lisp/linum.el 2012-01-19 07:21:25 +0000 > +++ lisp/linum.el 2013-01-15 00:45:27 +0000 > @@ -151,7 +151,7 @@ > (run-hooks 'linum-before-numbering-hook) > ;; Create an overlay (or reuse an existing one) for each > ;; line visible in this window, if necessary. > - (while (and (not (eobp)) (<= (point) limit)) > + (while (and (not (eobp)) (< (point) limit)) > (let* ((str (if fmt > (propertize (format fmt line) 'face 'linum) > (funcall linum-format line))) > > # Begin bundle > IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdjgvvgAABJfgAAQQGFxUBIA > AACv794QIABkRTaajamQyGjTaRiFGgBMBBkwQhDmaVnH5r9hMFQyJ7EUzThiw4Ixc/mQVpexbPS2 > 9yLLTxaFbWvXcN2zcydOQxpD652acQC4g4Z96jI5BipgKAAiM5Zz45Kd/4u5IpwoSGxwX3wA From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Nathan Trapuzzano Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Oct 2013 21:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 13446@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.13828239531860 (code B ref -1); Sat, 26 Oct 2013 21:46:01 +0000 Received: (at submit) by debbugs.gnu.org; 26 Oct 2013 21:45:53 +0000 Received: from localhost ([127.0.0.1]:46212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaBg8-0000Tm-OG for submit@debbugs.gnu.org; Sat, 26 Oct 2013 17:45:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37050) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaBg5-0000TV-Ij for submit@debbugs.gnu.org; Sat, 26 Oct 2013 17:45:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VaBfs-0000X4-5I for submit@debbugs.gnu.org; Sat, 26 Oct 2013 17:45:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaBfr-0000Wz-VM for submit@debbugs.gnu.org; Sat, 26 Oct 2013 17:45:36 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaBfk-0000T6-Pl for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2013 17:45:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VaBfd-0000W1-Rp for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2013 17:45:28 -0400 Received: from oproxy13-pub.mail.unifiedlayer.com ([69.89.16.30]:60941) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1VaBfd-0000Vt-HB for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2013 17:45:21 -0400 Received: (qmail 3068 invoked by uid 0); 26 Oct 2013 21:44:56 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy13.mail.unifiedlayer.com with SMTP; 26 Oct 2013 21:44:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:To:From; bh=1kPe8pJV5RG9y1GIS17uUaD9zQIsFw5rcrerP2yT0DY=; b=NlaLpGElkUKOyBoFSKHjZOlHnJSQwVkJw5HyNz+mOt88IQN22UIfQ9WI04yMDXDaV5gbZFgi7RA7uicmwOpYCHRXl1+ydKLyVjMyNrQ2+gQeAmdChW3cce9Pjgrv/ZUI; Received: from [50.90.253.209] (port=42957 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1VaBfD-0001BG-RD for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2013 15:44:56 -0600 From: Nathan Trapuzzano References: <87mwwb2ej5.fsf@nbtrap.com> Date: Sat, 26 Oct 2013 17:44:54 -0400 In-Reply-To: <87mwwb2ej5.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Tue, 15 Jan 2013 00:36:46 -0500") Message-ID: <87mwlvzoyx.fsf@nbtrap.com> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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-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 (----) Any reason why this hasn't been accepted? From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2013 04:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nathan Trapuzzano Cc: 13446@debbugs.gnu.org Received: via spool by 13446-submit@debbugs.gnu.org id=B13446.138284761211426 (code B ref 13446); Sun, 27 Oct 2013 04:21:01 +0000 Received: (at 13446) by debbugs.gnu.org; 27 Oct 2013 04:20:12 +0000 Received: from localhost ([127.0.0.1]:46860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaHpi-0002yB-Rt for submit@debbugs.gnu.org; Sun, 27 Oct 2013 00:20:11 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:48438) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaHpf-0002xj-W5 for 13446@debbugs.gnu.org; Sun, 27 Oct 2013 00:20:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/hu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJBOICwbBLY0ag3ADpHqBXoMTgUs X-IPAS-Result: Av4EABK/CFFLd/hu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJBOICwbBLY0ag3ADpHqBXoMTgUs X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="36440838" Received: from 75-119-248-110.dsl.teksavvy.com (HELO pastel.home) ([75.119.248.110]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Oct 2013 00:20:01 -0400 Received: by pastel.home (Postfix, from userid 20848) id 97C8E60038; Sun, 27 Oct 2013 00:20:01 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> Date: Sun, 27 Oct 2013 00:20:01 -0400 In-Reply-To: <874n85cqxj.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Fri, 25 Oct 2013 11:26:32 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) 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.3 (/) > Any reason why this hasn't been accepted? On my end, it's mostly for lack of time. But having just looked at it, I can't see what the problem is about really. I mean, your patch looks fine, but it's not clear what it's fixing. I've read your explanation, but I think it's too subtle to explain with only text. I just installed your patch into trunk, since it looks sane. But I'd be interested to hear a concrete description of the problematic behavior this bug could introduce. Stefan > Nathan Trapuzzano writes: >> There is an incorrect loop test in linum.el that potentially applies an >> overlay to a line not visible in the window and thereby messes up the >> width of the overlays in the lines that are visible. The patch/merge >> directive is attached, and what follows is the commit message: >> >> ----- >> >> Modify loop test in `linum-update-window'. >> >> `limit' is set to the position returned by `window-end'; this position >> is either on the last visible (logical) line in the buffer or is the >> first position on the line following the last visible line. In the >> former case, the loop variable never reaches the value of `limit', but >> in the latter case, an overlay is applied to a line that is not >> visible in the window. This can mess up the width of the overlay on >> the visible lines, especially if the width of the line number (as a >> string) of the line that's not visible is different from the width of >> the visible lines' line numbers. >> # Bazaar merge directive format 2 (Bazaar 0.90) >> # revision_id: nbtrap@nbtrap.com-20130115010121-h7kwjyr5kimowgml >> # target_branch: . >> # testament_sha1: a9154d3ede2b389220646bb8e9e708117d876d01 >> # timestamp: 2013-01-14 20:03:26 -0500 >> # base_revision_id: nbtrap@nbtrap.com-20130111013646-pn4xh5r94x5asomb >> # >> # Begin patch >> === modified file 'lisp/linum.el' >> --- lisp/linum.el 2012-01-19 07:21:25 +0000 >> +++ lisp/linum.el 2013-01-15 00:45:27 +0000 >> @@ -151,7 +151,7 @@ >> (run-hooks 'linum-before-numbering-hook) >> ;; Create an overlay (or reuse an existing one) for each >> ;; line visible in this window, if necessary. >> - (while (and (not (eobp)) (<= (point) limit)) >> + (while (and (not (eobp)) (< (point) limit)) >> (let* ((str (if fmt >> (propertize (format fmt line) 'face 'linum) >> (funcall linum-format line))) >> >> # Begin bundle >> IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdjgvvgAABJfgAAQQGFxUBIA >> AACv794QIABkRTaajamQyGjTaRiFGgBMBBkwQhDmaVnH5r9hMFQyJ7EUzThiw4Ixc/mQVpexbPS2 >> 9yLLTxaFbWvXcN2zcydOQxpD652acQC4g4Z96jI5BipgKAAiM5Zz45Kd/4u5IpwoSGxwX3wA From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Nathan Trapuzzano Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2013 11:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 13446@debbugs.gnu.org Received: via spool by 13446-submit@debbugs.gnu.org id=B13446.138287488926987 (code B ref 13446); Sun, 27 Oct 2013 11:55:01 +0000 Received: (at 13446) by debbugs.gnu.org; 27 Oct 2013 11:54:49 +0000 Received: from localhost ([127.0.0.1]:47372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaOvf-00071C-Fv for submit@debbugs.gnu.org; Sun, 27 Oct 2013 07:54:48 -0400 Received: from oproxy13-pub.mail.unifiedlayer.com ([69.89.16.30]:40028) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VaOva-00070s-8m for 13446@debbugs.gnu.org; Sun, 27 Oct 2013 07:54:43 -0400 Received: (qmail 5565 invoked by uid 0); 27 Oct 2013 11:54:40 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy13.mail.unifiedlayer.com with SMTP; 27 Oct 2013 11:54:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=m1qWexIEoq4QyIDhNnRM48Qyc11omDSPW6w8AINQZwI=; b=cRIPzFtFC4Z1QzCTjIszOQQgyxvD3S7ugB65wZecix//umyG9rk8fozu2TEN+NEc3nh0Ss4maTivhDANYq9WH/suQGNKGZTHQBHtFhCtGDyxJ57Pfaa8/iFoggw+ZtHO; Received: from [50.90.253.209] (port=53828 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1VaOvY-0005eH-8F; Sun, 27 Oct 2013 05:54:40 -0600 From: Nathan Trapuzzano References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> Date: Sun, 27 Oct 2013 07:54:35 -0400 In-Reply-To: (Stefan Monnier's message of "Sun, 27 Oct 2013 00:20:01 -0400") Message-ID: <87y55fapz8.fsf@nbtrap.com> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) 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.0 (/) The gist of it is that linum is in most cases applying an overlay to a line not visible in the window, which can cause the width of the overlays of the lines that _are_ in the window to get messed up. Given linum's default behavior, this is never actually a problem; it is only potentially a problem for people who customize the linum formatting (via the `linum-format' variable), as I found out. Let me try to explain it in more detail. By default, linum will make a margin large enough to fit the line number of the last line in the buffer. (Technically, for the purpose of determining the last line, linum correctly ignores the actual last line if it is empty. That's what the (not (eobp)) is doing. But nevermind that for now.) So if the buffer is 2000 lines long (talking about logical lines here), the margin in which the line numbers are displayed is four characters wide, even if the window itself is only showing, e.g., lines 200-250. Now, suppose you want linum to display a margin only wide enough to hold the highest line number of the lines currently displayed in the _window_ (as opposed to all the lines in the buffer). You do this by setting `linum-format' to "%d". Now, if your window is showing lines 1-50, the margin will only be two characters wide, even if there are 2000 lines in the entire buffer. However, this gets messes up on edge cases. Try this yourself: Set `linum-format' to "%d", switch to a buffer with 100 or more lines, and put point somewhere such that the highest line displayed in the window is some line between 10 and 98 inclusive. Notice how the margin on the left is two characters wide. Now, put point somewhere such that the highest line displayed is line 99. (Also, (1) make sure that the end of line 99 is itself visible in the window; and (2) if 100 is the highest line in the entire buffer, make sure it is not empty.) Notice now that the margin for line numbers is three characters wide--large enough to hold "100", even though line 100 is not actually in the window. This is caused by linum overlaying line 100, which it shouldn't be doing. My patch fixes this. Nathan Stefan Monnier writes: >> Any reason why this hasn't been accepted? > > On my end, it's mostly for lack of time. But having just looked at it, > I can't see what the problem is about really. I mean, your patch looks > fine, but it's not clear what it's fixing. I've read your explanation, > but I think it's too subtle to explain with only text. > > I just installed your patch into trunk, since it looks sane. > > But I'd be interested to hear a concrete description of the problematic > behavior this bug could introduce. > > > Stefan > > >> Nathan Trapuzzano writes: > >>> There is an incorrect loop test in linum.el that potentially applies an >>> overlay to a line not visible in the window and thereby messes up the >>> width of the overlays in the lines that are visible. The patch/merge >>> directive is attached, and what follows is the commit message: >>> >>> ----- >>> >>> Modify loop test in `linum-update-window'. >>> >>> `limit' is set to the position returned by `window-end'; this position >>> is either on the last visible (logical) line in the buffer or is the >>> first position on the line following the last visible line. In the >>> former case, the loop variable never reaches the value of `limit', but >>> in the latter case, an overlay is applied to a line that is not >>> visible in the window. This can mess up the width of the overlay on >>> the visible lines, especially if the width of the line number (as a >>> string) of the line that's not visible is different from the width of >>> the visible lines' line numbers. >>> # Bazaar merge directive format 2 (Bazaar 0.90) >>> # revision_id: nbtrap@nbtrap.com-20130115010121-h7kwjyr5kimowgml >>> # target_branch: . >>> # testament_sha1: a9154d3ede2b389220646bb8e9e708117d876d01 >>> # timestamp: 2013-01-14 20:03:26 -0500 >>> # base_revision_id: nbtrap@nbtrap.com-20130111013646-pn4xh5r94x5asomb >>> # >>> # Begin patch >>> === modified file 'lisp/linum.el' >>> --- lisp/linum.el 2012-01-19 07:21:25 +0000 >>> +++ lisp/linum.el 2013-01-15 00:45:27 +0000 >>> @@ -151,7 +151,7 @@ >>> (run-hooks 'linum-before-numbering-hook) >>> ;; Create an overlay (or reuse an existing one) for each >>> ;; line visible in this window, if necessary. >>> - (while (and (not (eobp)) (<= (point) limit)) >>> + (while (and (not (eobp)) (< (point) limit)) >>> (let* ((str (if fmt >>> (propertize (format fmt line) 'face 'linum) >>> (funcall linum-format line))) >>> >>> # Begin bundle >>> IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdjgvvgAABJfgAAQQGFxUBIA >>> AACv794QIABkRTaajamQyGjTaRiFGgBMBBkwQhDmaVnH5r9hMFQyJ7EUzThiw4Ixc/mQVpexbPS2 >>> 9yLLTxaFbWvXcN2zcydOQxpD652acQC4g4Z96jI5BipgKAAiM5Zz45Kd/4u5IpwoSGxwX3wA From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2013 13:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nathan Trapuzzano Cc: 13446@debbugs.gnu.org Received: via spool by 13446-submit@debbugs.gnu.org id=B13446.13828812074459 (code B ref 13446); Sun, 27 Oct 2013 13:41:02 +0000 Received: (at 13446) by debbugs.gnu.org; 27 Oct 2013 13:40:07 +0000 Received: from localhost ([127.0.0.1]:47418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaQZZ-00019q-Kq for submit@debbugs.gnu.org; Sun, 27 Oct 2013 09:40:06 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:50261) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaQZU-00019B-J6 for 13446@debbugs.gnu.org; Sun, 27 Oct 2013 09:40:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsoXua/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IPAS-Result: Av4EABK/CFFsoXua/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="36449654" Received: from 108-161-123-154.dsl.teksavvy.com (HELO pastel.home) ([108.161.123.154]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Oct 2013 09:39:53 -0400 Received: by pastel.home (Postfix, from userid 20848) id 2355D60460; Sun, 27 Oct 2013 09:39:41 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> <87y55fapz8.fsf@nbtrap.com> Date: Sun, 27 Oct 2013 09:39:41 -0400 In-Reply-To: <87y55fapz8.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Sun, 27 Oct 2013 07:54:35 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) 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.3 (/) > not empty.) Notice now that the margin for line numbers is three > characters wide--large enough to hold "100", even though line 100 is not > actually in the window. This is caused by linum overlaying line 100, > which it shouldn't be doing. My patch fixes this. Ah, got it! Thank you, it makes perfect sense now, BTW, in nlinum-mode, the default behavior is half-way between the two: we don't try to accommodate the largest line number there can be (partly to avoid scanning the whole buffer, which can be a performance problem in itself), so we grow the margin only when we display a larger number, but we don't shrink it back when moving back to the beginning of the file with shorter line numbers. The main reason was that I found it annoying to have the margin grow&shrink all the time in those cases where you're working right around line 100 or 1000. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 27 10:01:49 2013 Received: (at control) by debbugs.gnu.org; 27 Oct 2013 14:01:49 +0000 Received: from localhost ([127.0.0.1]:47583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaQua-0001hb-KN for submit@debbugs.gnu.org; Sun, 27 Oct 2013 10:01:48 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:31674) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaQuY-0001hL-Hx for control@debbugs.gnu.org; Sun, 27 Oct 2013 10:01:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsoXua/2dsb2JhbABEvw4Xc4IfAQUZPTMLNBIUGA2ISMEtjWGDKQOkeoFegxM X-IPAS-Result: Av4EABK/CFFsoXua/2dsb2JhbABEvw4Xc4IfAQUZPTMLNBIUGA2ISMEtjWGDKQOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="36450344" Received: from 108-161-123-154.dsl.teksavvy.com (HELO pastel.home) ([108.161.123.154]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Oct 2013 10:01:40 -0400 Received: by pastel.home (Postfix, from userid 20848) id 988F860460; Sun, 27 Oct 2013 10:01:38 -0400 (EDT) From: Stefan Monnier To: control@debbugs.gnu.org Subject: Re: bug#13446: 24.2; Fix loop test in linum.el Message-ID: References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> <87y55fapz8.fsf@nbtrap.com> Date: Sun, 27 Oct 2013 10:01:38 -0400 In-Reply-To: (Stefan Monnier's message of "Sun, 27 Oct 2013 09:39:41 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: control 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.3 (/) close 13446 thanks From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Nathan Trapuzzano Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2013 19:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 13446@debbugs.gnu.org Received: via spool by 13446-submit@debbugs.gnu.org id=B13446.13829025769197 (code B ref 13446); Sun, 27 Oct 2013 19:37:01 +0000 Received: (at 13446) by debbugs.gnu.org; 27 Oct 2013 19:36:16 +0000 Received: from localhost ([127.0.0.1]:47727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VaW8F-0002OH-TE for submit@debbugs.gnu.org; Sun, 27 Oct 2013 15:36:16 -0400 Received: from oproxy12-pub.mail.unifiedlayer.com ([50.87.16.10]:51541) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VaW8D-0002O7-2D for 13446@debbugs.gnu.org; Sun, 27 Oct 2013 15:36:14 -0400 Received: (qmail 29694 invoked by uid 0); 27 Oct 2013 19:36:11 -0000 Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy12.mail.unifiedlayer.com with SMTP; 27 Oct 2013 19:36:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=4MJwS7KM96fjATGhBFfwXktJmnRL7ykp39PM2B9MjHM=; b=TJiLhEigNjlyBcY6ZjUM3yjFOg39JorKAHoBwIQZBF1Kqh5Z1Yc4vUNgAcIXrCp/fQaRbGr67IR0+3BQJW/LqqQsOn70vomaAic4MC/ahJW9ju5fC+I/6jX5hUDksxJm; Received: from [50.90.253.209] (port=53962 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (TLSv1:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1VaW8B-0007wn-9T; Sun, 27 Oct 2013 13:36:11 -0600 From: Nathan Trapuzzano References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> <87y55fapz8.fsf@nbtrap.com> Date: Sun, 27 Oct 2013 15:36:07 -0400 In-Reply-To: (Stefan Monnier's message of "Sun, 27 Oct 2013 09:39:41 -0400") Message-ID: <87r4b68q1k.fsf@nbtrap.com> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-Spam-Score: 0.0 (/) 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.0 (/) The behavior you describe is actually doable using a combination of `linum-before-numbering-hook' and `linum-format'. (In particular, I'm talking about setting `linum-format' to a symbol, which will cause linum to call the function with that symbol's name to retrieve the line number as a string.) I know because I've implemented it, or something very similar to it, myself. Indeed, given these two variables, linum is actually very capable. On the other hand, one seeminly irreparable problem with linum is _when_ it applies the overlays--or when it doesn't. I'm not sure if there's a bug report for this, but faily often linum won't display the overlays at all, or will only display the line numbers on some of the lines in the window. This happens especially frequently when bouncing on balanced parens/brackets via `forward-' and `backward-sexp'. If something is going to replace linum, I'd be very interested to know whether it fixes this problem. Do you happen to know? Stefan Monnier writes: > BTW, in nlinum-mode, the default behavior is half-way between the two: > we don't try to accommodate the largest line number there can be > (partly to avoid scanning the whole buffer, which can be a performance > problem in itself), so we grow the margin only when we display a larger > number, but we don't shrink it back when moving back to the beginning of > the file with shorter line numbers. From unknown Mon Aug 18 15:41:39 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13446: 24.2; Fix loop test in linum.el Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Oct 2013 00:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13446 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nathan Trapuzzano Cc: 13446@debbugs.gnu.org Received: via spool by 13446-submit@debbugs.gnu.org id=B13446.13829206009632 (code B ref 13446); Mon, 28 Oct 2013 00:37:01 +0000 Received: (at 13446) by debbugs.gnu.org; 28 Oct 2013 00:36:40 +0000 Received: from localhost ([127.0.0.1]:47927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vaaox-0002VH-HB for submit@debbugs.gnu.org; Sun, 27 Oct 2013 20:36:39 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:18833) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vaaou-0002V4-ME for 13446@debbugs.gnu.org; Sun, 27 Oct 2013 20:36:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsr+u9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJBOICwbBLZEKA6R6gV6DEw X-IPAS-Result: Av4EABK/CFFsr+u9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJBOICwbBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="36471724" Received: from 108-175-235-189.dsl.teksavvy.com (HELO pastel.home) ([108.175.235.189]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Oct 2013 20:36:31 -0400 Received: by pastel.home (Postfix, from userid 20848) id D878860036; Sun, 27 Oct 2013 20:36:30 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> <87y55fapz8.fsf@nbtrap.com> <87r4b68q1k.fsf@nbtrap.com> Date: Sun, 27 Oct 2013 20:36:30 -0400 In-Reply-To: <87r4b68q1k.fsf@nbtrap.com> (Nathan Trapuzzano's message of "Sun, 27 Oct 2013 15:36:07 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) 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.3 (/) > parens/brackets via `forward-' and `backward-sexp'. If something is > going to replace linum, I'd be very interested to know whether it fixes > this problem. Do you happen to know? The intended replacement is nlinum.el (you can install it via M-x list-packages). But it is not as hackable as linum.el (nothing equivalent to linum-before-numbering-hook). Stefan > Stefan Monnier writes: >> BTW, in nlinum-mode, the default behavior is half-way between the two: >> we don't try to accommodate the largest line number there can be >> (partly to avoid scanning the whole buffer, which can be a performance >> problem in itself), so we grow the margin only when we display a larger >> number, but we don't shrink it back when moving back to the beginning of >> the file with shorter line numbers.