bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37488: 27.0.50; Inconsistent naming of arg of `text-property-search-


From: Eli Zaretskii
Subject: bug#37488: 27.0.50; Inconsistent naming of arg of `text-property-search-forward' and `-backward'
Date: Thu, 26 Sep 2019 22:24:47 +0300

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: michael_heerdegen@web.de,  lekktu@gmail.com,  37488@debbugs.gnu.org
> Date: Thu, 26 Sep 2019 21:16:19 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (text-property-search-forward 'face 'bold nil)
> >> 
> >> and
> >> 
> >> (text-property-search-forward 'face 'bold
> >>                               (lambda (val p-val) (not (equal val p-val))))
> >> 
> >> The latter will stop every time 'face changes, while the former stops in
> >> a way that segments the buffer in all the regions that have not 'face
> >> 'bold.
> >
> > You are saying that the latter will also stop where there's no 'face'
> > property at all, while the former will only stop where there _is_
> > 'face', but it is not 'bold'?  IOW, nil is equivalent to
> >
> >   (lambda (val p-val) (and p-val (not (equal val p-val))))
> 
> No, not the same, I'm afraid.  nil means "when looping over this search,
> give me all regions where 'face is not bold", while your predicate will
> give you all regions where there is a 'face property, but it's not nil.

OK, the example is bad, but I did get the meaning.

> >> >> What it's meant to do is basically how TAB works in buttons, which is a
> >> >> common use case.  If you're looking for "o", and point is where "|" is
> >> >> below, then it'll find the last "oo" section after the x-es:
> >> >> 
> >> >> oo|oxxxxxoo
> >> >
> >> > What does "o" stand for in this case?
> >> 
> >> Text with "o" as the property.
> >
> > But then the code should reject the second "oo" section because the
> > value of the property there is equal to the value at point.  Right?
> 
> Oh, that's the confusion.  By "doesn't include point", I meant "doesn't
> include the region point was at when the search started".

But that's not what the code seems to do.  It just compares the value
of property in the found region with that at point.  In this example,
they both are "o", so the code will reject the "oo" region at the end,
and try to find the next one (and fail, because there's none).

> >> > I don't understand how this answers my questions.
> >> 
> >> Try (text-property-search-forward 'face) on the example.  It'll give you
> >> all regions that has a face property.
> >
> > That's a weird way to get to the result, if someone wants it.
> 
> Seems like the obvious way to me.

The obvious one would be to call next-single-property-change.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]