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

From: Howard Melman <[email-masked]>
Date: Mon, 10 May 2021 09:06:08 -0400

On May 10, 2021, at 5:05 AM, Lars Ingebrigtsen <[email-masked]> 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