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: Wed, 21 Apr 2010 19:17:30 -0700 Message-ID: References: <837ho6czb6.fsf@gnu.org> <8339yucbsg.fsf@gnu.org> <83wrw5bxkc.fsf@gnu.org> <83tyr9bgid.fsf@gnu.org> <83r5mcbqzo.fsf@gnu.org> Reply-To: mark.lillibridge@hp.com NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271902679 32434 80.91.229.12 (22 Apr 2010 02:17:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2010 02:17:59 +0000 (UTC) Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 22 04:17:57 2010 connect(): No such file or directory 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 1O4lzI-0000x8-Oh for ged-emacs-devel@m.gmane.org; Thu, 22 Apr 2010 04:17:57 +0200 Original-Received: from localhost ([127.0.0.1]:54092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4lzH-00043o-W2 for ged-emacs-devel@m.gmane.org; Wed, 21 Apr 2010 22:17:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4lzC-00041S-5D for emacs-devel@gnu.org; Wed, 21 Apr 2010 22:17:50 -0400 Original-Received: from [140.186.70.92] (port=33407 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4lzA-0003zF-DQ for emacs-devel@gnu.org; Wed, 21 Apr 2010 22:17:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4lz8-0002VP-K0 for emacs-devel@gnu.org; Wed, 21 Apr 2010 22:17:48 -0400 Original-Received: from madara.hpl.hp.com ([192.6.19.124]:49980) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4lz8-0002VF-As; Wed, 21 Apr 2010 22:17:46 -0400 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 o3M2HXUX011397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Apr 2010 19:17:33 -0700 (PDT) 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 o3M2HUlG029488; Wed, 21 Apr 2010 19:17:31 -0700 In-reply-to: <83r5mcbqzo.fsf@gnu.org> (message from Eli Zaretskii on Sun, 18 Apr 2010 20:38:35 +0300) 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-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:124009 Archived-At: Eli Zaretskii wrote: > Mark Lillibridge wrote: > > The issue is that font-lock mode, goto-line, linum mode, and perhaps > > other features need to treat them differently. These features want to > > widen to the "application" restriction when processing the current > > buffer, ignoring any temporary restriction. > > But if this is the problem you want to solve, you cannot solve it by > introducing yet another kind of restriction: there's always a chance > that a command will want to use the "application" restriction, when > one is already in place, because, e.g., you have font-lock or whatever > active. And then you are back at the same problem. > > IOW, by introducing 2 kinds of restriction, you don't solve the > problem, you just push it a bit farther. > > Moreover, I'm not sure I see the problem that is grave enough to > justify this. The 3 examples you mentioned can be solved by > programming the features to do what you want (I believe font-lock > already solved it, albeit not too elegantly). I understand now the > difference between two classes of use of restriction (thanks to all > who labored to explain that to this old fart), but are there > _practical_ use-cases where the current situation gets in our way so > badly that such a new feature would be justified? I wonder. Personally, the problem I need fixed is that goto-line and linum mode number lines inconsistently. Given that linum mode already numbers the first line of a restriction starting with one and Info mode looks weird if we start numbering at the beginning of the physical buffer, I think the minimal change would be to change goto-line to number lines so that the first line of the current restriction is 1. Some wanted an option to control whether line numbers were numbered from the beginning of the restriction or the beginning of the physical buffer and some (others?) to solve this problem (which characters really belong to the (logical) buffer) once and for all. - Mark