From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 11 Apr 2010 22:27:05 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271039687 12645 80.91.229.12 (12 Apr 2010 02:34:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Apr 2010 02:34:47 +0000 (UTC) Cc: lekktu@gmail.com, drew.adams@oracle.com, markus.triska@gmx.at, emacs-devel@gnu.org To: mark.lillibridge@hp.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 12 04:34:45 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 1O19U1-0000fT-42 for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 04:34:41 +0200 Original-Received: from localhost ([127.0.0.1]:42102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O19U0-0001K9-G4 for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 22:34:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O19Tu-0001J0-R1 for emacs-devel@gnu.org; Sun, 11 Apr 2010 22:34:34 -0400 Original-Received: from [140.186.70.92] (port=55246 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O19To-0001DJ-It for emacs-devel@gnu.org; Sun, 11 Apr 2010 22:34:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O19Mg-0001RG-Q6 for emacs-devel@gnu.org; Sun, 11 Apr 2010 22:27:08 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:33851 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O19Mg-0001RB-GT for emacs-devel@gnu.org; Sun, 11 Apr 2010 22:27:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFANIhwktMCqWu/2dsb2JhbACPbotTcrZOhQwEi0Y X-IronPort-AV: E=Sophos;i="4.52,187,1270440000"; d="scan'208";a="60642883" Original-Received: from 76-10-165-174.dsl.teksavvy.com (HELO pastel.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 11 Apr 2010 22:27:05 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 57BAF7F1B; Sun, 11 Apr 2010 22:27:05 -0400 (EDT) In-Reply-To: (Mark Lillibridge's message of "Sun, 11 Apr 2010 15:22:21 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) 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:123510 Archived-At: > 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. This does sound right. And yes, it might introduce some "far" changes, but hopefully it will still be fairly limited. One visible change that's missing in the above is that we need to have two forms of widening: whether we want to widen the current temporary narrowing (if any), or we want to widen it all (i.e. not only the temporary narrowing but the semantic one as well). An important part of the design is to try and minimize the amount of changes to the C code (which currently keeps track of BEG and Z which are the widened limits of the buffer and BEGV and ZV which are the current narrowed buffer limits). So ideally, the distinction between the two kinds of narrowing would only be visible to Elisp code. Stefan