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

[Stephen Berman]

On Tue, 11 May 2021 15:28:48 -0400 Howard Melman <hmelman@gmail.com> wrote:

> To me, this function behaves unexpectedly different in these cases
> (say in a font-locked elisp buffer just before the last defun):
>
>     ;; a region with property face is found,
>     ;; point is moved to the end of it
>     (text-property-search-forward 'face)
>
>     ;; a region with property unused is not found,
>     ;; point is unmoved
>     (text-property-search-forward 'unused)
>
>     ;; a region with the specfied face is found,
>     ;; point is moved to the beginning of it
>     (text-property-search-forward 'face 'font-lock-function-name-face)
>
>     ;; a region with the specfied face is not found,
>     ;; point is moved to eob
>     (text-property-search-forward 'face 'unused)
>
>     ;; a region with the specfied property is not found,
>     ;; point is moved to eob
>     (text-property-search-forward 'unused-prop 'unused-value)
>
> The first two behave perfectly reasonably to me.  And as the manual
> suggests, behaves the same as search-forward.
>
> The 3rd does as well, of course.
>
> I'd expect both the 4th and the 5th to behave the same as the 2nd but
> they move point to eob.
>
> And while I now mostly understand (but don't fully grok) the logic,
> it's baffling to me that to make the last three behave like the first
> two I should set PREDICATE to t (and btw doing so changes the behavior
> of the 3rd to leave point at the end of the match instead of the
> beginning, which seems odd).

It's behaving as documented: without t, the search found some other
value of 'face (possibly nil) not equal to 'font-lock-function-name-face
and moved to the end of the thus propertized text, as documented.  You
should see this in the return value (shown as a message), which could be
something like this: #s(prop-match 37 41 nil)

> The difference between the 3rd and 4th isn't some subtle difference
> between using equal and eq or something, it's that the specified value
> of the face is not found as it was using the default predicate in the
> 3rd case.

No, in the third case the search stopped before the specified value was
found.

>            And particularly in the 5th, the choice of predicate to
> evaluate 'unused-value shouldn't come into play because 'unused-prop
> itself isn't found.
>
> And the documentation describing PREDICATE nil didn't help me at all.
> In the manual it says for nil:
>
>     (which means “not equal”)
>
> which sounds to me as if it is using the function not.  
>
> And in your updated docstring as:
>
>     a value will match if is not `equal' to VALUE
>
> which really throws me because the 3rd case above works and it's 
> not "not `equal'" to font-lock-function-name-face!

Again, this is correct: the found value (possibly nil, as illustrated
above) is not equal to 'font-lock-function-name-face.

> Does this explain my confusion?
>
> I interpret all of these:
>
>     (search-forward "defun")
>     (text-property-search-forward 'face)
>     (text-property-search-forward 'face 'font-lock-function-name-face)
>
> to mean search for the thing I specified, whether that's a string, a
> specific property with any value or a specific property with a
> specific value.  But somehow the last one is different. And try as I
> might now to write how it's being interpreted I'm unable to. Search
> for the property face but only if it is font-lock-function-name-face
> or if it isn't...?

In light of the above explanations, is it clearer now?

Steve Berman