Subject: bug#10387: CODE wishlist: search-prop.el

From: Stefan Monnier <[email-masked]>
Date: Fri, 13 Apr 2012 09:03:42 -0400

>> > I like this.  Gnus uses text properties extensively, and searching for
>> > them using the standard functions (`next-property-change' and friends)
>> > is a hassle.
>> > `search-property' looks like what I have needed in the past.
>> text-property-any (and t-p-not-all) seems to do the same, except it only
>> searches forward.  Is there some other difference I'm missing (other
>> than the `cycle' which doesn't seem tremendously useful)?
> Differences compared to text-property-any:
>  - Includes helper functions 'search-property-forward' and
>   'search-property-backward' which move point and closely match the
>   interface and behavior of 'search-forward' and 'search-backward'.
>   (Except for 'count'.)  The interactive use is nice: when you need
>   it, you really need it.

I can't remember needing such a thing, but maybe it's just because it
didn't occur to me.

>  - I don't remember what the original use case was for 'cycle'.  Possibly
>    to emulate the effect of hitting TAB in Emacs Muse to go to the next URL
>    (behavior that I would remove if I was starting again from scratch).

I guess the cycle makes sense for interactive use, tho it can be
implemented on top of a non-cycling primitive.

So all in all, I think the main points are:
- search backward.
- UI.
- names with "search" and with direction.
I actually like it, so I suggest to provide new functions
(search-text-property-forward START END PROP VALUE &optional OBJECT NOT-EQ)
and search-text-property-backward, implemented in C and then reimplement
text-property-any and text-property-not-all in Elisp on top of them (and
make them obsolete).

        Stefan