From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: question about narrowed behavior of next-property-change et al. Date: 24 Jan 2003 15:06:12 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: Reply-To: Miles Bader NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1043388505 20087 80.91.224.249 (24 Jan 2003 06:08:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2003 06:08:25 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18bx0p-0005Dp-00 for ; Fri, 24 Jan 2003 07:08:23 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18bx3Q-0000Kz-00 for ; Fri, 24 Jan 2003 07:11:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18bx0V-0001a6-03 for emacs-devel@quimby.gnus.org; Fri, 24 Jan 2003 01:08:03 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18bx03-0001JK-00 for emacs-devel@gnu.org; Fri, 24 Jan 2003 01:07:35 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18bwzE-0000k0-00 for emacs-devel@gnu.org; Fri, 24 Jan 2003 01:06:45 -0500 Original-Received: from tyo201.gate.nec.co.jp ([210.143.35.51]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18bwyp-0000TJ-00; Fri, 24 Jan 2003 01:06:19 -0500 Original-Received: from mailgate4.nec.co.jp ([10.7.69.197])h0O66Ew17389; Fri, 24 Jan 2003 15:06:14 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate52.nec.co.jp [10.7.69.198]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h0O66D809121; Fri, 24 Jan 2003 15:06:13 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h0O66CH27788; Fri, 24 Jan 2003 15:06:12 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) id h0O66CB09501; Fri, 24 Jan 2003 15:06:12 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 22C593738; Fri, 24 Jan 2003 15:06:12 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: Original-Lines: 25 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11028 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11028 Richard Stallman writes: > I think if there's no property change before (point-max), and the > user passed LIMIT == nil, then it should return nil, regardless of > whether (point-max) is due to narrowing or not. > > It is certainly more logical that way--the question is, what will it > break? It would be necessary to check all the programs that use > next-property-change and make sure they are still going to work. Since the suggested change would only effect narrowed buffers, and only to make them act more like a normal non-narrowed buffer, I would think that only code that explicitly uses narrowing is potentially a problem (under the assumption that a narrowed buffer should usually appear to lisp code as if it were a normal buffer containing only the narrowed region). Since most code is written assume a `normal' buffer, I suspect the net effect of the current wierd behavior is to cause problems with such code expecting the usual non-narrowed behavior in the rare case where it is used with a narrowed buffer. -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest?