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: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 11 Apr 2010 15:22:21 -0700 Message-ID: References: Reply-To: mark.lillibridge@hp.com NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271041516 16466 80.91.229.12 (12 Apr 2010 03:05:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Apr 2010 03:05:16 +0000 (UTC) Cc: lekktu@gmail.com, drew.adams@oracle.com, markus.triska@gmx.at, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 12 05:05:14 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 1O19xY-00083Q-B2 for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 05:05:12 +0200 Original-Received: from localhost ([127.0.0.1]:37076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O19xX-0000fW-FO for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 23:05:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O15Y9-0004bT-D2 for emacs-devel@gnu.org; Sun, 11 Apr 2010 18:22:41 -0400 Original-Received: from [140.186.70.92] (port=35689 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O15Y7-0004bJ-KA for emacs-devel@gnu.org; Sun, 11 Apr 2010 18:22:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O15Y6-0004mX-2W for emacs-devel@gnu.org; Sun, 11 Apr 2010 18:22:39 -0400 Original-Received: from ngundega.hpl.hp.com ([192.6.19.100]:34007) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O15Y5-0004mR-LA for emacs-devel@gnu.org; Sun, 11 Apr 2010 18:22:38 -0400 Original-Received: from mailhub-pa1.hpl.hp.com (mailhub-pa1.hpl.hp.com [15.25.115.25]) by ngundega.hpl.hp.com (8.14.3/8.14.3/HPL-PA Relay) with ESMTP id o3BMMRmN016273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Apr 2010 15:22:27 -0700 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 o3BMMLMM004968; Sun, 11 Apr 2010 15:22:21 -0700 In-reply-to: (message from Stefan Monnier on Mon, 15 Feb 2010 15:13:07 -0500) X-Scanned-By: MIMEDefang 2.67 on 15.0.48.100 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Mailman-Approved-At: Sun, 11 Apr 2010 23:05:06 -0400 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:123511 Archived-At: [sorry for the delay replying] Stefan wrote: > Mark wrote: > > (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) > > The problem is not one of line-numbers but of narrowing/restriction only > (which in turn has impacts on line-numbering among other things). > So I don't think "number" deserves to be part of the name. > > While implementing it, please try and merge it with (AKA have it replace) > font-lock-dont-widen. > > Of course, a better approach would distinguish the two kinds of > narrowing not on a buffer-basis but on a narrowing-basis, so that if you > interactively narrow to a portion of a page in an Info buffer, you > can still get line-numbers starting at the beginning of the page > (even if it's outside the narrowed portion). Hmmm. I think some more design may be in order before implementing. Let me try and sketch an idea based on the above: * There are two (optional) levels of restriction: "semantic" and "temporary". (better names anyone?) * The temporary restriction is always contained in or the same as the semantic one. * font-lock always uses the semantic restriction (font-lock-dont-widen goes away) * By default, line numbering is also based on the semantic restriction * a global option allows switching this behavior to use the temporary restriction for line numbering. * Rmail, Info, and the like, use the semantic restriction because the restricted-to-unit is effectively an independent buffer (semantic unit) * The default narrowing commands available to users use the temporary restriction. Does this sort of approach make sense? Do people like it? It is a more global change than I was originally envisioning. - Mark