From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Possible `point-entered' `point-left' Text Property Bug Date: Mon, 15 May 2006 12:14:43 -0400 Message-ID: <87y7x3i7t8.fsf@mit.edu> References: <87r7304jck.fsf@stupidchicken.com> <873bfff7x2.fsf@stupidchicken.com> <87mzdmyme4.fsf@stupidchicken.com> <87u07styso.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1147709686 27778 80.91.229.2 (15 May 2006 16:14:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 May 2006 16:14:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 15 18:14:40 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FffiA-0006lp-EP for ged-emacs-devel@m.gmane.org; Mon, 15 May 2006 18:14:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fffi9-0004Uh-Pn for ged-emacs-devel@m.gmane.org; Mon, 15 May 2006 12:14:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fffhv-0004S9-LH for emacs-devel@gnu.org; Mon, 15 May 2006 12:14:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fffht-0004RL-L5 for emacs-devel@gnu.org; Mon, 15 May 2006 12:14:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fffht-0004RI-HI for emacs-devel@gnu.org; Mon, 15 May 2006 12:14:05 -0400 Original-Received: from [18.19.6.82] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FffkI-00051q-JR; Mon, 15 May 2006 12:16:34 -0400 Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 9D2771200AA; Mon, 15 May 2006 12:14:43 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Mon, 15 May 2006 01:13:01 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:54515 Archived-At: > > Hmm, I agree that scanning from point-min is somewhat odd. > > Maybe it would be better to use (line-beginning-position) > > instead of (point-min) as the starting point. What do you think? > > Does that make it work? > > Not always. For example, when point-left and point-entered are placed > over an interval that does not cover the line-beginning position, as > shown: > > | interval | > 1 2 3 4_5 6 7 8 9 > ^ point is here > > The scenario is not fully specified, so I am not sure what the code > will do, nor can I start to think about whether it is right or wrong. > > Could you try making a completely specified scenario, and show > what the code will do? (defun prop-test (old new) (message "XXX: %d %d" old new)) (let ((buffer (generate-new-buffer "*prop tst*"))) (with-current-buffer buffer (insert "12345\n12345\n12345") (goto-char 16) (put-text-property 8 (point-max) 'point-entered 'prop-test) (put-text-property 8 (point-max) 'point-left 'prop-test) (pop-to-buffer buffer))) This brings up a buffer with contents (ignore the spaces, which are there for illustrative purposes): 1 2 3 4 5 1*2 3 4 5 1 2 3|4 5* where the region between the asterisks has non-nil `point-entered' and `point-left' properties, and point is placed at the position indicated by `|'. Now do C-p. The `point-entered' hook, `prop-test', is called. This is wrong, since point is moving inside the region. That's because in the middle of line-move-finish, when handling intangibility, we bind inhibit-point-motion-hooks to nil and move point to (point-min): |1 2 3 4 5 1*2 3 4 5 1 2 3 4 5* (or, as you suggested, line-beginning-position): 1 2 3 4 5 |1*2 3 4 5 1 2 3 4 5* and then to the target position: 1 2 3 4 5 1*2 3|4 5 1 2 3 4 5* Either way, point leaves the region where point-entered/left is non-nil during this operation, so the point motion hooks are called. If you feel that fixing this is too much trouble before the release, how about simply adding a note to the documentation saying that line motion can call the point-entered/point-left hooks in unpredictable ways? I don't know any real-life code that breaks because of this, so maybe we shouldn't risk introducing bugs with tangibility by changing stuff now.