[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48317: 27.1; text-property-search-forward moves point to end when no
From: |
Stephen Berman |
Subject: |
bug#48317: 27.1; text-property-search-forward moves point to end when not found |
Date: |
Wed, 12 May 2021 01:18:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, (continued)
- Message not available
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Eli Zaretskii, 2021/05/09
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Howard Melman, 2021/05/09
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Lars Ingebrigtsen, 2021/05/10
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Howard Melman, 2021/05/10
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Lars Ingebrigtsen, 2021/05/11
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Eli Zaretskii, 2021/05/11
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Lars Ingebrigtsen, 2021/05/11
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Howard Melman, 2021/05/11
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Lars Ingebrigtsen, 2021/05/11
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Howard Melman, 2021/05/11
- bug#48317: 27.1; text-property-search-forward moves point to end when not found,
Stephen Berman <=
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Lars Ingebrigtsen, 2021/05/12
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Howard Melman, 2021/05/12
- bug#48317: 27.1; text-property-search-forward moves point to end when not found, Lars Ingebrigtsen, 2021/05/12