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: Wed, 9 Dec 2009 21:34:28 -0800 Message-ID: <200912100534.nBA5YSva008256@mailhub-pa1.hpl.hp.com> References: <200911260039.nAQ0dTD1019384@mailhub-pa1.hpl.hp.com> Reply-To: mark.lillibridge@hp.com, 5042@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1260424067 2406 80.91.229.12 (10 Dec 2009 05:47:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2009 05:47:47 +0000 (UTC) Cc: 5042@emacsbugs.donarmstrong.com, control@emacsbugs.donarmstrong.com To: lekktu@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 10 06:47:40 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 1NIbsJ-0005zy-OK for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Dec 2009 06:47:40 +0100 Original-Received: from localhost ([127.0.0.1]:35394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIbsJ-0000og-ES for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Dec 2009 00:47:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIbsE-0000nC-Gx for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2009 00:47:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIbs9-0000iw-I4 for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2009 00:47:33 -0500 Original-Received: from [199.232.76.173] (port=40373 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIbs9-0000it-7n for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2009 00:47:29 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50010) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NIbs8-0003UK-NT for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2009 00:47:29 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBA5lQM9016231; Wed, 9 Dec 2009 21:47:26 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id nBA5e4Ps015582; Wed, 9 Dec 2009 21:40:04 -0800 Resent-Date: Wed, 9 Dec 2009 21:40:04 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Mark Lillibridge Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Thu, 10 Dec 2009 05:40:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 5042 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 5042-submit@emacsbugs.donarmstrong.com id=B5042.126042328115137 (code B ref 5042); Thu, 10 Dec 2009 05:40:04 +0000 Original-Received: (at 5042) by emacsbugs.donarmstrong.com; 10 Dec 2009 05:34:41 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from madara.hpl.hp.com (madara.hpl.hp.com [192.6.19.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBA5YdNx015132; Wed, 9 Dec 2009 21:34:41 -0800 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 nBA5YU0o013689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Dec 2009 21:34:30 -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 nBA5YSva008256; Wed, 9 Dec 2009 21:34:28 -0800 In-reply-to: (message from Juanma Barranquero on Tue, 1 Dec 2009 01:32:26 +0100) X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-From: mark.lillibridge@hp.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Thu, 10 Dec 2009 00:47:33 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list 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:33453 Archived-At: > On Thu, Nov 26, 2009 at 01:39, Mark Lillibridge wrote: > > >    Linum-mode does not work correctly with buffers that have been > > narrowed.  As a simple example, type ^h i.  You will note that the first > > line is assigned line number one.  You can verify that this is wrong > > either by using goto-line > > Let's hear Markus' opinion, but IMHO that's not necessarily a bug. > Linum's function is to add line numbers, but these do not have to > correspond to buffer lines. For example, nothing stops you from doing > > (defvar my-num 1000) > (make-variable-buffer-local 'my-num) > > (setq linum-format (lambda (n) (format "%4d" (+ n my-num)))) > > > Juanma The entire point of having line numbers is that they correspond to something useful. Either an external program's line number (e.g., a gcc error number) or an internal Emacs notion such as that provided by goto-line. The current behavior does neither. Note that other line numbering modes like wb-line-number implement the behavior that I describe as correct. I cannot see any useful circumstance where linum and goto-line should disagree about what line number a given line has. I can see an argument that some buffers like RMAIL and info might want to start numbering lines at one for the visible part of the buffer; I see this as a possible feature request where say a buffer local variable specifies this behavior. Note that that feature might be hard to implement correctly because there is no hook for changing the buffer restriction visible to the user. That is, even if you believe that feature should be the default/only behavior, the current code is still broken because changing the restriction does not update the line numbers correctly. - Mark