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

[Chong Yidong]

Richard Stallman <address@hidden> writes:

>           ;; Process intangibility within a line.
>           ;; Move to the chosen destination position from above,
>           ;; with intangibility processing enabled.
>
>           (goto-char (point-min))
>           (let ((inhibit-point-motion-hooks nil))
>             (goto-char new)
>
>     Here, inhibit-point-motion-hooks is bound to nil to avoid processing
>     the intangible property.  But this also has the effect of spuriously
>     calling point-left and point-entered hooks if they are defined.  I
>     hacked around this by changing it to
>
>           (goto-char new)
>           (let ((inhibit-point-motion-hooks nil))
>             (goto-char new)
>
> I think that change is incorrect.  That code is supposed
> to run the hooks in a controlled way.  Your change makes it
> a no-op.
>
> Why do you believe the old code is wrong?

Because of the bug report that started all this: suppose the
properties `point-entered' and `point-left' are defined over the
entire interval (point-min) to (point-max), and point is in the middle
of a line, as shown:

 1 2 3|4 5
 1 2 3 4 5

Now, suppose we call `next-line'.  The part of `line-move-finish' that
processes intangibility, shown above, first moves point from its
original position to point-min, rebinds inhibit-point-motion-hooks to
nil, then moves to the desired point:

|1 2 3 4 5
 1 2 3 4 5

 1 2 3 4 5
 1 2 3|4 5

Since there is no point before point-min, and
inhibit-point-motion-hooks is nil during the second point motion, the
point-entered/left hooks will be called.  This is wrong, since the
initial and final points of the `next-line' command have identical
`point-entered' and `point-left' properties.

See `line-move-finish' for details.

Of course, if you decide that it's OK for the point motion hooks to be
spuriously called in some situations, that's fine by me; I'll revert
the changes and add a note to the Elisp manual to that effect.