GNU bug report logs -
#48317
27.1; text-property-search-forward moves point to end when not found
Previous Next
Reported by: Howard Melman <hmelman <at> gmail.com>
Date: Sun, 9 May 2021 16:42:02 UTC
Severity: normal
Found in version 27.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #44 received at 48317 <at> debbugs.gnu.org (full text, mbox):
On Tue, 11 May 2021 15:28:48 -0400 Howard Melman <hmelman <at> 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
This bug report was last modified 3 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.