bug#21271: 25.0.5; `field' text-property screws with `line-end-position'

bug#21271: 25.0.5; `field' text-property screws with `line-end-position'

[Artur Malabarba]

1. In an empty buffer, hit RET and type some text on the second line.
2. Place point at the start of the second line.
3. Run (line-end-position) and verify that the value is correct
(something greater than 3)
4. Run (add-text-properties (1- (point)) (point) '(field 1))
5. Run (line-end-position) and you'll get 2 (which is the poistion of
the end of the field).

bug#21271: 25.0.5; `field' text-property screws with `line-end-position'

[Drew Adams]

Confirmed.  This is the case as far back as property `field' has
existed, AFAICT.  (It is not the case for Emacs 20, which has no
built-in property `field'.  It is the case for Emacs 22.  Dunno
about 21.)

But this part of the doc string seems to indicate that this behavior
is to be expected:

 This function constrains the returned position to the current field
 unless that would be on a different line than the original,
 unconstrained result.  If N is nil or 1, and a rear-sticky field ends
 at point, the scan stops as soon as it starts.  To ignore field
 boundaries bind ‘inhibit-field-text-motion’ to t.

> 1. In an empty buffer, hit RET and type some text on the second
> line.
> 2. Place point at the start of the second line.
> 3. Run (line-end-position) and verify that the value is correct
> (something greater than 3)
> 4. Run (add-text-properties (1- (point)) (point) '(field 1))
> 5. Run (line-end-position) and you'll get 2 (which is the poistion
> of the end of the field).

bug#21271: 25.0.5; `field' text-property screws with `line-end-position'

[Artur Malabarba]

Thanks Drew. I was so used to this function and so surprised about
this behavior that it didn't even occur to me to read the docstring
more carefully. That even explains how to prevent it.
I'm closing this now.