bug#48317: 27.1; text-property-search-forward moves point to end when not found

[Howard Melman]

On May 10, 2021, at 5:05 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> I think the doc string is wrong -- you rewrote it in 165890a and further
> in df05c26.  The original doc string was correct, I think:
> 
> +Some convenience values for PREDICATE can also be used.  `t'
> +means the same as `equal'.  `nil' means almost the same as \"not
> +equal\", but will also end the match if the value of PROPERTY
> +changes.  See the manual for extensive examples.
> 
> The code performs as originally documented in the test case from Howard,
> as far as I can tell.

Ok, setting property to t solves both of my cases.

What threw me (and I still think is problematic) is this line from the 
docstring:

    If not found, return nil and don't move point.

And this line from the manual:

     If the text property can’t be found, the function returns ‘nil’.

Which I assume also infers point is not moved. If no region has the named 
property I can't see how it can be found and therefore point should not be 
moved.  In fact I don't see how predicate even comes into play in this case.  

I still think there's a bug here:

    ;; We're standing in the property we're looking for, so find the
    ;; end.
    ((and (text-property--match-p value (get-text-property (point) property)
                                  predicate)
          (not not-current))
     (text-property--find-end-forward (point) property value predicate))

Because this solves my problem:

    ((and (get-text-property (point) property)
          (text-property--match-p value (get-text-property (point) property)
                                  predicate)
          (not not-current))
     (text-property--find-end-forward (point) property value predicate))

Howard