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

From: Lars Ingebrigtsen <[email-masked]>
Date: Wed, 12 May 2021 16:16:55 +0200

Howard Melman <[email-masked]> writes:

> 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)

The doc string in Emacs 27 is misleading, because it doesn't emphasise
the meaning of PREDICATE.

What the form above does is look for areas where there's a text property
named `face' that uses the nil predicate on a nil value.  :-)

That is, it finds all areas where the `face' property is not nil --
VALUE is nil, and PREDICATE is nil.

>     ;; 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)

No, here you're looking for regions where `face' is not
`font-lock-function-name-face' -- which will indeed leave you at the
start of the region where `face' is `font-lock-function-name-face', but
that's not really what the function matched.

But I understand your confusion now.  The function searches for areas
where a text property is matching something (according to PREDICATE),
and leaves point at the end of the match.  You, instead, expect it to
leave point at the start of the match, which is the opposite of what it
does.

Hm...  Oh!  That's wrong in the doc string, too -- it says that it moves
point to the start of the region, which it certainly doesn't.  I've now
fixed this in the two doc strings.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no