From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathan Trapuzzano Newsgroups: gmane.emacs.bugs Subject: bug#16413: 24.3.50; Inconsistent behavior of text property functions in narrowed buffer Date: Sat, 11 Jan 2014 14:43:11 -0500 Message-ID: <87zjn25mpc.fsf@nbtrap.com> References: <87mwj3fcal.fsf@nbtrap.com> <52D0C30D.9050305@dancol.org> <52D0C401.90208@dancol.org> <87eh4e677p.fsf@nbtrap.com> <83txdaacnp.fsf@gnu.org> <87eh4e1v8o.fsf@nbtrap.com> <83mwj2a9hq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389469453 19894 80.91.229.3 (11 Jan 2014 19:44:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 19:44:13 +0000 (UTC) Cc: 16413@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 11 20:44:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W24Ti-0007RA-8X for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Jan 2014 20:44:18 +0100 Original-Received: from localhost ([::1]:35270 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W24Th-0002ED-Su for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Jan 2014 14:44:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W24TY-0002Do-T7 for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 14:44:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W24TS-00057s-Sc for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 14:44:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W24TS-00057n-PT for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 14:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W24TS-0005QV-2w for bug-gnu-emacs@gnu.org; Sat, 11 Jan 2014 14:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Nathan Trapuzzano Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Jan 2014 19:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16413 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16413-submit@debbugs.gnu.org id=B16413.138946940520796 (code B ref 16413); Sat, 11 Jan 2014 19:44:01 +0000 Original-Received: (at 16413) by debbugs.gnu.org; 11 Jan 2014 19:43:25 +0000 Original-Received: from localhost ([127.0.0.1]:47064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W24Sq-0005PL-Pr for submit@debbugs.gnu.org; Sat, 11 Jan 2014 14:43:25 -0500 Original-Received: from alt-proxy6.mail.unifiedlayer.com ([66.147.245.65]:37081) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1W24Sm-0005P9-5U for 16413@debbugs.gnu.org; Sat, 11 Jan 2014 14:43:21 -0500 Original-Received: (qmail 10357 invoked by uid 0); 11 Jan 2014 19:43:15 -0000 Original-Received: from unknown (HELO host393.hostmonster.com) (66.147.240.193) by oproxy14.mail.unifiedlayer.com with SMTP; 11 Jan 2014 19:43:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbtrap.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=Y++ZVEgFYSJv7cJh1/dijMPebGWWhfUdK17g6BGAIRs=; b=iOhKLO09pPNdv9mqbq2M9slLNJmvxsUYDwhpJzTCVJQZQ7/8+xlaCMXt/ydV/cISC3JkQruBsoG73LleSoZso947jBPFaq3gxA2oJt1qSVD4fZO0IhdNELx4q2D5vc0S; Original-Received: from [50.90.253.209] (port=35159 helo=Nathan-GNU) by host393.hostmonster.com with esmtpsa (UNKNOWN:CAMELLIA128-SHA:128) (Exim 4.80) (envelope-from ) id 1W24Sh-0001Bg-Ba; Sat, 11 Jan 2014 12:43:15 -0700 In-Reply-To: <83mwj2a9hq.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Jan 2014 16:17:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Identified-User: {1585:host393.hostmonster.com:nbtrapco:nbtrap.com} {sentby:smtp auth 50.90.253.209 authed with nbtrap@nbtrap.com} X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:83311 Archived-At: Eli Zaretskii writes: >> char-after is a primitive, and it behaves intuitively at (point-max) on >> narrowed buffers. Why shouldn't other functions behave consistently? > > I don't know. One reason could be that we might need a primitive that > can report properties of characters that are not reachable. But I > don't have any evidence to that effect. Even if there were such a need, it could always be achieved with `save-restriction', etc. On the other hand, users should be able to expect that functions behave consistently with respect to narrowing, and these clearly don't >> Nevermind about the search functions. I was confused about the behavior >> of previous-single-property-change. The problem lies in the functions >> that fetch the properties. > > The usual paradigm is to search for a possible place where the you > might have the property, then examine the properties at that point. > With this paradigm, if you never look at the properties when the > search hits the limit of the search, you will never have this problem. I was confused by how `previous-single-property-change' actually doesn't look at the property at POSITION. It starts looking at (1- position) and then find the first difference from that point. It's not intuitive, but it makes sense if you think about it.