bug#47564: text-property-search-forward does not behave as advertized

["Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Nicolas Graner <nicolas@graner.name> writes:

>
> (insert "12345678")
> (put-text-property 3 6 'foo 'bar)
> (goto-char 1)
> (text-property-search-forward 'foo 'bar t)
> ;; moves point to 6 and returns range 3 to 6
> ;; Doc says it should move the point to start of range, but it
> ;; consistently moves to end of range.

I see this was changed in
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b295174210465c4285729c67ec014e0f5b53f741,
but I don't know about the reasons for the change.  In any case, the
docstring is now inconsistent with the documentation in the Elisp
manual, which says that point is placed at the end (which matches the
implementation).  I've CC Stefan, but I think the docstring error is
that `text-property-search-forward' moves point to the end of the
matched region, and `text-property-search-backward' moves point to the
beginning of the matched region.

> (goto-char 1)
> (text-property-search-forward 'foo 'bar nil)
> ;; moves point to 3 and returns range 1 to 3, whre property foo is nil.
> ;; Doc says: with PREDICATE nil, a value will match if it is
> ;; non-nil and is NOT ‘equal’ to VALUE.
> ;; In fact, the condition "it is non-nil" is apparently ignored.

After reading the code, I'd say you're correct and the "non-nil" is
ignored in the implementation.  This part was added in response to this
bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37488, perhaps
I'm missing something.

> (goto-char 9)
> (text-property-search-backward 'foo 'bar t)
> ;; moves point to 3 and returns range 3 to 6
> ;; As above, consistently moves to beginning of range instead of end.

I think this is the same documentation bug as the first one.

> (goto-char 7)
> (text-property-search-backward 'foo 'bar t)
> ;; returns nil. This one is really weird, considering it works OK from
> ;; position 6 or 8. As if there was something special when you start 1
> ;; after the end of a range.

Yes, this seems like an off-by-one error in the implementation.