From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathan Trapuzzano Newsgroups: gmane.emacs.bugs Subject: bug#13446: 24.2; Fix loop test in linum.el Date: Sun, 27 Oct 2013 07:54:35 -0400 Message-ID: <87y55fapz8.fsf@nbtrap.com> References: <87y5fvp7ti.fsf@nbtrap.com> <874n85cqxj.fsf@nbtrap.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1382874915 26430 80.91.229.3 (27 Oct 2013 11:55:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Oct 2013 11:55:15 +0000 (UTC) Cc: 13446@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 27 12:55:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VaOwA-0002Hz-GO for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2013 12:55:18 +0100 Original-Received: from localhost ([::1]:37462 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaOwA-00069U-1p for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2013 07:55:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaOw2-00069P-5L for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 07:55:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VaOvw-00077k-4G for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 07:55:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VaOvv-00073Q-5l for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 07:55:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VaOvu-00071g-0c for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 07:55:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 13446-submit@debbugs.gnu.org id=B13446.138287488926987 (code B ref 13446); Sun, 27 Oct 2013 11:55:01 +0000 Original-Received: (at 13446) by debbugs.gnu.org; 27 Oct 2013 11:54:49 +0000 Original-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 Original-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 Original-Received: (qmail 5565 invoked by uid 0); 27 Oct 2013 11:54:40 -0000 Original-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; Original-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 In-Reply-To: (Stefan Monnier's message of "Sun, 27 Oct 2013 00:20:01 -0400") User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79692 Archived-At: 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