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: Sat, 17 Apr 2010 12:51:17 -0700 Message-ID: References: <837ho6czb6.fsf@gnu.org> <8339yucbsg.fsf@gnu.org> Reply-To: mark.lillibridge@hp.com NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271535850 1096 80.91.229.12 (17 Apr 2010 20:24:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Apr 2010 20:24:10 +0000 (UTC) Cc: 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 Sat Apr 17 22:24:09 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 1O3EYe-0005Z3-7n for ged-emacs-devel@m.gmane.org; Sat, 17 Apr 2010 22:24:08 +0200 Original-Received: from localhost ([127.0.0.1]:48211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3EYb-00061D-EC for ged-emacs-devel@m.gmane.org; Sat, 17 Apr 2010 16:24:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3E3A-0002uf-FL for emacs-devel@gnu.org; Sat, 17 Apr 2010 15:51:32 -0400 Original-Received: from [140.186.70.92] (port=35938 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3E35-0002qi-Ac for emacs-devel@gnu.org; Sat, 17 Apr 2010 15:51:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3E33-0000Zm-BU for emacs-devel@gnu.org; Sat, 17 Apr 2010 15:51:27 -0400 Original-Received: from gundega.hpl.hp.com ([192.6.19.190]:50772) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3E33-0000ZY-1K; Sat, 17 Apr 2010 15:51:25 -0400 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.3/HPL-PA Relay) with ESMTP id o3HJpKp4010567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Apr 2010 12:51:21 -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 o3HJpHnf011350; Sat, 17 Apr 2010 12:51:18 -0700 In-reply-to: <8339yucbsg.fsf@gnu.org> (message from Eli Zaretskii on Sat, 17 Apr 2010 18:57:03 +0300) X-Scanned-By: MIMEDefang 2.67 on 15.0.48.190 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Mailman-Approved-At: Sat, 17 Apr 2010 16:21:09 -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:123818 Archived-At: Eli wrote: > > From: Stefan Monnier > > Cc: mark.lillibridge@hp.com, emacs-devel@gnu.org > > Date: Sat, 17 Apr 2010 10:45:19 -0400 > > > > > What are these two ``kinds'' of restriction you are talking about, and > > > how are they relevant to the issue at hand, which is how to number > > > lines when a buffer is narrowed? > > > > He's proposing to distinguish between two different kinds of narrowing > > (aka "restrictions"). > > Yes, but what _are_ these two kinds? How are they different from one > another? Sorry, I should've explained better. Originally, the issue was just how to do line numbering, but Stefan suggested widening the issue. Broadly speaking, the issue arises with "applications" like Rmail and Info that use a single Emacs buffer as what amounts to a collection of logical buffers; they switch among these logical buffers by restricting the Emacs buffer to the logical buffer in question. Thus, for example Rmail restricts my inbox file to just the current message. When I advance to a different message, it changes the restriction to the new message. Info is similar, but instead of messages, it is nodes(?). Unfortunately, many Emacs features don't expect this and so behave suboptimally. For example, font lock attempts to process the entire buffer instead of just the current logical buffer; font-lock-dont-widen was invented to allow these applications to prevent this. The example which started this discussion is line numbering: goto-line numbers lines based on the physical buffer while linum mode numbers lines based on the logical buffer (actually, the current restriction). Things get even messier when the user narrows the (logical) buffer temporarily, say to limit macro application. If the application used font-lock-dont-widen, then font locking will attempt to run only on the temporary restriction, probably with confusing results. The intuition is that these two kinds of restrictions, the first for creating logical buffers, and the second for temporary limitation of commands, are fundamentally different and should be distinguished. Does that make more sense? - Mark