Re: Possible `point-entered' `point-left' Text Property Bug

[Chong Yidong]

>     > 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.