From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Lillibridge Newsgroups: gmane.emacs.bugs Subject: bug#5042: 23.1; linum-mode gives incorrect line numbers with narrowed buffers Date: Sun, 20 Dec 2009 22:59:43 -0800 Message-ID: <200912210659.nBL6xhDG020940@mailhub-pa1.hpl.hp.com> References: <200911260039.nAQ0dTD1019384@mailhub-pa1.hpl.hp.com> <200912100534.nBA5YSva008256@mailhub-pa1.hpl.hp.com> Reply-To: mark.lillibridge@hp.com, 5042@debbugs.gnu.org NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1261379440 2234 80.91.229.12 (21 Dec 2009 07:10:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2009 07:10:40 +0000 (UTC) Cc: 5042@emacsbugs.donarmstrong.com To: lekktu@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 21 08:10:32 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NMcPR-0000cl-L4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Dec 2009 08:10:26 +0100 Original-Received: from localhost ([127.0.0.1]:53505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMcPR-00011F-K2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Dec 2009 02:10:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMcPL-000112-F8 for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2009 02:10:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMcPF-00010Z-OS for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2009 02:10:18 -0500 Original-Received: from [199.232.76.173] (port=56574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMcPF-00010O-J6 for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2009 02:10:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42854) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NMcPF-0002wZ-A3 for bug-gnu-emacs@gnu.org; Mon, 21 Dec 2009 02:10:13 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NMcLB-0004be-Kc; Mon, 21 Dec 2009 02:06:01 -0500 X-Loop: bug-gnu-emacs@gnu.org Mail-Followup-To: mark.lillibridge@hp.com, 5042@debbugs.gnu.org Resent-From: Mark Lillibridge Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Dec 2009 07:06:01 +0000 Resent-Message-ID: Resent-Sender: bug-gnu-emacs@gnu.org X-Emacs-PR-Message: followup 5042 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 5042-submit@debbugs.gnu.org id=B5042.126137912717699 (code B ref 5042); Mon, 21 Dec 2009 07:06:01 +0000 Original-Received: (at 5042) by debbugs.gnu.org; 21 Dec 2009 07:05:27 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMcKc-0004bQ-Sy for submit@debbugs.gnu.org; Mon, 21 Dec 2009 02:05:27 -0500 Original-Received: from madara.hpl.hp.com ([192.6.19.124]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NMcFJ-0004Yn-D9 for 5042@emacsbugs.donarmstrong.com; Mon, 21 Dec 2009 01:59:58 -0500 Original-Received: from mailhub-pa1.hpl.hp.com (mailhub-pa1.hpl.hp.com [15.25.115.25]) by madara.hpl.hp.com (8.14.3/8.14.1/HPL-PA Relay) with ESMTP id nBL6xjR7013296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Dec 2009 22:59:45 -0800 (PST) Original-Received: from ts-rhel4.hpl.hp.com (ts-rhel4.hpl.hp.com [15.25.118.24]) by mailhub-pa1.hpl.hp.com (8.14.3/8.14.3/HPL-PA Hub) with ESMTP id nBL6xhDG020940; Sun, 20 Dec 2009 22:59:43 -0800 In-reply-to: (message from Juanma Barranquero on Thu, 10 Dec 2009 12:41:21 +0100) X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-From: mark.lillibridge@hp.com X-Mailman-Approved-At: Mon, 21 Dec 2009 02:05:25 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 21 Dec 2009 02:06:01 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:33710 Archived-At: Okay, let us see where we stand: * Juanma uses linum mode to know how many lines there are in a file (or a region, if narrowing is in effect) at a glance; they do not use go to line. * Mark (aka, me) and others specify lines to act on by reading off line numbers provided by linum and use goto-line to implement voice commands; it is crucial for this purpose that the line numbers provided correspond to the line numbers goto-line uses in all cases, including for non-current buffers. * linum mode currently does what Juanma wants. * A somewhat non-obvious and fragile hook function can convert the current mode into what Mark wants: (add-hook 'linum-before-numbering-hook (function (lambda () (setq line (save-restriction (widen) (line-number-at-pos)))))) (line here is a local variable of the linum-update-window, bound shortly before the hook is called; needless to say, this modification is unlikely to continue working as the linum code evolves.) * I think you can build a less fragile hook by using a custom version of linum-format, however, this interferes with the ability to use linum-format for any other purpose. * Both modes produce surprises: Juanma's causes surprises when goto-line goes to the wrong line in some buffers and Mark's causes surprises when some buffers start with a line number greater than one. Using Juanma's mode plus changing the behavior of goto-line would produce no obvious surprises, but I cannot be sure that changing goto-line does not mess something else up. I think that given that Mark's mode is likely to be useful enough of the time and that implementing it is nontrivial, especially for beginners, there should be an explicit option to switch between the modes. The default should probably depend on which surprise people think is worse. I can live with either way. I am willing to take a stab at trying to implement such an option if people think this is a good idea. - Mark