From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Lillibridge Newsgroups: gmane.emacs.devel Subject: Emacs's handling of line numbers [from bug#5042] Date: Mon, 15 Feb 2010 10:47:33 -0800 Message-ID: Reply-To: mark.lillibridge@hp.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1266259880 14467 80.91.229.12 (15 Feb 2010 18:51:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Feb 2010 18:51:20 +0000 (UTC) Cc: lekktu@gmail.com, markus.triska@gmx.at, drew.adams@oracle.com To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 15 19:51:17 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nh62O-0002JH-8i for ged-emacs-devel@m.gmane.org; Mon, 15 Feb 2010 19:51:16 +0100 Original-Received: from localhost ([127.0.0.1]:35251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nh62N-0003p6-QQ for ged-emacs-devel@m.gmane.org; Mon, 15 Feb 2010 13:51:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nh5zK-0002mX-Mt for emacs-devel@gnu.org; Mon, 15 Feb 2010 13:48:06 -0500 Original-Received: from [140.186.70.92] (port=46646 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nh5zK-0002mM-3T for emacs-devel@gnu.org; Mon, 15 Feb 2010 13:48:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nh5zJ-0006j7-81 for emacs-devel@gnu.org; Mon, 15 Feb 2010 13:48:05 -0500 Original-Received: from gundega.hpl.hp.com ([192.6.19.190]:65281) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nh5zI-0006hk-Vj for emacs-devel@gnu.org; Mon, 15 Feb 2010 13:48:05 -0500 Original-Received: from mailhub-pa1.hpl.hp.com (mailhub-pa1.hpl.hp.com [15.25.115.25]) by gundega.hpl.hp.com (8.14.3/8.14.1/HPL-PA Relay) with ESMTP id o1FIlZhI026235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Feb 2010 10:47:35 -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 o1FIlXYq008148; Mon, 15 Feb 2010 10:47:33 -0800 X-MailScanner-ID: o1FIlZhI026235 X-HPL-MailScanner: Found to be clean X-HPL-MailScanner-From: mark.lillibridge@hp.com X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Mon, 15 Feb 2010 13:50:24 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121133 Archived-At: [Moved here from bug tracker bug #5042; subject line was "RE: bug#5042: 23.1;linum-mode gives incorrect line numbers with narrowed buffers"] Gnu emacs's assignment of line numbers to lines is inconsistent when a buffer is narrowed: * goto-line and (not part of standard emacs) wb-line-number.el always starts numbering lines from the start of the buffer but, * line-number-at-pos and linum mode start numbering lines from (point-min) so a given line's line number depends on what restriction (if any) is in effect at the moment. This has a number of bad consequences; perhaps most importantly, it is not possible to reliably jump to a on-screen line using goto-line and its displayed line number. (This is a crucial primitive for controlling emacs via voice.) After some discussion on the bug tracker list, it was agreed that all of these functions should be made consistent. Because both methods of numbering lines have defenders and uses: * always numbering from the start of the buffer makes it easy to see that you're in a restriction and to compare to external line numbers (e.g., as produced by gcc) * numbering from the start of a restriction makes it easy to see how big the restriction is; it also makes modes like Rmail or info have "normal" line numbers. (Otherwise, you get counterintuitive effects like Rmail messages starting with line number 242634.) the consensus was that the method of line numbering should be customizable/settable on a per buffer basis. To be concrete, the current proposal is to add something like: (defcustom restart-numbering-restriction nil "If true, lines inside a restriction are numbered starting from 1. If false, line numbers correspond to position inside the buffer." :group 'editing-basics :type 'boolean) goto-line, line-number-at-pos, and linum mode would then use the current value of this variable to decide how to number lines. Modes like Rmail and info would make this variable buffer local and set it to t. There was no strong consensus on the default value for this variable other than that no one felt strongly about its value. A weak preference was expressed for nil. Opinions? If this proposal is acceptable, I volunteer to produce a draft patch implementing it. - Mark