GNU bug report logs -
#37488
27.0.50; Inconsistent naming of arg of `text-property-search-forward' and `-backward'
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37488 in the body.
You can then email your comments to 37488 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Mon, 23 Sep 2019 06:04:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 23 Sep 2019 06:04:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
the last optional argument of `text-property-search-forward' and
`text-property-search-backward' is named "not-immediate", but the manual
calls it "not-current" (seems since it was added by Lars). That's all -
please fix the inconsistency.
Thanks,
Michael.
Reply sent
to
Juanma Barranquero <lekktu <at> gmail.com>:
You have taken responsibility.
(Mon, 23 Sep 2019 07:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>:
bug acknowledged by developer.
(Mon, 23 Sep 2019 07:32:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 37488-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've fixed it using NOT-CURRENT, which seems marginally clearer.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Mon, 23 Sep 2019 07:48:04 GMT)
Full text and
rfc822 format available.
Message #13 received at 37488-done <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero <lekktu <at> gmail.com> writes:
> I've fixed it using NOT-CURRENT, which seems marginally clearer.
Yes, that's good. Thanks for fixing.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 08:53:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 23 Sep 2019 09:30:20 +0200
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 37488-done <at> debbugs.gnu.org
>
> I've fixed it using NOT-CURRENT, which seems marginally clearer.
Thanks.
I had more problems with these doc strings, so I rewrote them. Please
take a look.
I have a couple of questions regarding the documentation, which I
couldn't easily figure out. Please help me understand them and
improve the documentation further:
. The original doc string said about nil as PREDICATE:
`nil' means almost the same as \"not equal\", but will also
end the match if the value of PROPERTY changes.
What does it mean to "end the match if the value changes"? The
text went on to say "See the manual for extensive examples", but
the manual doesn't mention this aspect of nil, it just says "not
equal".
. The doc string stated:
If NOT-CURRENT, if the match is under point, it will not be
returned, but instead the next instance is returned, if any.
But the code, AFAIU, just checks whether the value of PROPERTY at
point matches that of the found region, which doesn't necessarily
mean point is part of the region, it could just mean there are two
regions with matching values of PROPERTY, and point belongs to one
of them. Right?
. What is the reason for having VALUE an optional argument? Is it a
frequent/useful operation to look for a VALUE of nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 09:36:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> . What is the reason for having VALUE an optional argument? Is it a
> frequent/useful operation to look for a VALUE of nil?
I also wondered about the optional args, semantics is a bit unusual:
note that PREDICATE -> nil means "not equal", so with VALUE -> nil this
actually searches for non-nil values of the text property, which is a
reasonable (and the expected) default behavior. I needed to read it
twice.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 09:45:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, Lars Ingebrigtsen
> <larsi <at> gnus.org>, 37488 <at> debbugs.gnu.org
> Date: Wed, 25 Sep 2019 11:35:01 +0200
>
> note that PREDICATE -> nil means "not equal", so with VALUE -> nil this
> actually searches for non-nil values of the text property, which is a
> reasonable (and the expected) default behavior.
Is it? IME, we usually search for a specific value, not for any
value.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 10:17:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> > note that PREDICATE -> nil means "not equal", so with VALUE -> nil this
> > actually searches for non-nil values of the text property, which is a
> > reasonable (and the expected) default behavior.
>
> Is it? IME, we usually search for a specific value, not for any
> value.
For me, yes, the function fills a certain gap. But I'm not an expert on
that matter.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 10:27:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: lekktu <at> gmail.com, larsi <at> gnus.org, 37488 <at> debbugs.gnu.org
> Date: Wed, 25 Sep 2019 12:16:30 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > > note that PREDICATE -> nil means "not equal", so with VALUE -> nil this
> > > actually searches for non-nil values of the text property, which is a
> > > reasonable (and the expected) default behavior.
> >
> > Is it? IME, we usually search for a specific value, not for any
> > value.
>
> For me, yes, the function fills a certain gap.
Regardless, I think your and my surprise at the default is already a
good sign that the API is sub-optimal. After all, passing nil as a
mandatory argument is not an issue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 13:17:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> . The original doc string said about nil as PREDICATE:
>
> `nil' means almost the same as \"not equal\", but will also
> end the match if the value of PROPERTY changes.
>
> What does it mean to "end the match if the value changes"? The
> text went on to say "See the manual for extensive examples", but
> the manual doesn't mention this aspect of nil, it just says "not
> equal".
If point is inside a region where PROPERTY has a non-nil value, using
nil as the predicate will end the search when PROPERTY changes value.
> . The doc string stated:
>
> If NOT-CURRENT, if the match is under point, it will not be
> returned, but instead the next instance is returned, if any.
>
> But the code, AFAIU, just checks whether the value of PROPERTY at
> point matches that of the found region, which doesn't necessarily
> mean point is part of the region, it could just mean there are two
> regions with matching values of PROPERTY, and point belongs to one
> of them. Right?
I'm not sure I understand the question...
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 is the reason for having VALUE an optional argument? Is it a
> frequent/useful operation to look for a VALUE of nil?
If PREDICATE is nil, then having to use an explicit nil VALUE isn't
necessary.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 13:18:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> > note that PREDICATE -> nil means "not equal", so with VALUE -> nil this
>> > actually searches for non-nil values of the text property, which is a
>> > reasonable (and the expected) default behavior.
>>
>> Is it? IME, we usually search for a specific value, not for any
>> value.
>
> For me, yes, the function fills a certain gap. But I'm not an expert on
> that matter.
In my experience, we almost never search for a specific value for a text
property, but any text that has that property. That's why I added the
nil PREDICATE to avoid having to supply that awkward lambda into every
function I wrote...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 15:02:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, 37488 <at> debbugs.gnu.org,
> michael_heerdegen <at> web.de
> Date: Wed, 25 Sep 2019 15:15:58 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > . The original doc string said about nil as PREDICATE:
> >
> > `nil' means almost the same as \"not equal\", but will also
> > end the match if the value of PROPERTY changes.
> >
> > What does it mean to "end the match if the value changes"? The
> > text went on to say "See the manual for extensive examples", but
> > the manual doesn't mention this aspect of nil, it just says "not
> > equal".
>
> If point is inside a region where PROPERTY has a non-nil value, using
> nil as the predicate will end the search when PROPERTY changes value.
OK, but then it should be obvious, and explicitly mentioning that in
the doc string just makes it more confusing. Or am I missing
something?
> > . The doc string stated:
> >
> > If NOT-CURRENT, if the match is under point, it will not be
> > returned, but instead the next instance is returned, if any.
> >
> > But the code, AFAIU, just checks whether the value of PROPERTY at
> > point matches that of the found region, which doesn't necessarily
> > mean point is part of the region, it could just mean there are two
> > regions with matching values of PROPERTY, and point belongs to one
> > of them. Right?
>
> I'm not sure I understand the question...
The code doesn't seem to make sure point is inside the same region as
the one found by the initial attempt, it just compares the values of
PROPERTY at point and in the found region, and if they match, it looks
for another region. Is that a correct description of what the code
does when NOT-CURRENT is non-nil?
If the description is correct, then the doc string doesn't describe
what the code does accurately.
> 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?
> > . What is the reason for having VALUE an optional argument? Is it a
> > frequent/useful operation to look for a VALUE of nil?
>
> If PREDICATE is nil, then having to use an explicit nil VALUE isn't
> necessary.
I don't understand how this answers my questions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Wed, 25 Sep 2019 15:06:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, lekktu <at> gmail.com, 37488 <at> debbugs.gnu.org
> Date: Wed, 25 Sep 2019 15:17:11 +0200
>
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >> > note that PREDICATE -> nil means "not equal", so with VALUE -> nil this
> >> > actually searches for non-nil values of the text property, which is a
> >> > reasonable (and the expected) default behavior.
> >>
> >> Is it? IME, we usually search for a specific value, not for any
> >> value.
> >
> > For me, yes, the function fills a certain gap. But I'm not an expert on
> > that matter.
>
> In my experience, we almost never search for a specific value for a text
> property, but any text that has that property. That's why I added the
> nil PREDICATE to avoid having to supply that awkward lambda into every
> function I wrote...
We have different experiences, then.
In any case, the API uses double negation in the default case (find
text whose value of PROPERTY does NOT match no-value), which is
baaad...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 05:57:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I had more problems with these doc strings, so I rewrote them. Please
> take a look.
LGTM.
On thing: I'm not sure if it is obvious where a successful
`text-property-search-backward' leaves point - at the beginning or at
the end of the match?
Regards,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 07:34:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, Lars Ingebrigtsen
> <larsi <at> gnus.org>, 37488 <at> debbugs.gnu.org
> Date: Thu, 26 Sep 2019 07:55:57 +0200
>
> On thing: I'm not sure if it is obvious where a successful
> `text-property-search-backward' leaves point - at the beginning or at
> the end of the match?
That was in the original doc strings as well.
I have a couple more questions that didn't yet get answers to my
satisfaction; when that happens, I will try to handle this one as
well.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 14:43:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Ping! Please help me finish this job, thanks in advance.
> Date: Wed, 25 Sep 2019 18:01:34 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: michael_heerdegen <at> web.de, lekktu <at> gmail.com, 37488 <at> debbugs.gnu.org
>
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: Juanma Barranquero <lekktu <at> gmail.com>, 37488 <at> debbugs.gnu.org,
> > michael_heerdegen <at> web.de
> > Date: Wed, 25 Sep 2019 15:15:58 +0200
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > . The original doc string said about nil as PREDICATE:
> > >
> > > `nil' means almost the same as \"not equal\", but will also
> > > end the match if the value of PROPERTY changes.
> > >
> > > What does it mean to "end the match if the value changes"? The
> > > text went on to say "See the manual for extensive examples", but
> > > the manual doesn't mention this aspect of nil, it just says "not
> > > equal".
> >
> > If point is inside a region where PROPERTY has a non-nil value, using
> > nil as the predicate will end the search when PROPERTY changes value.
>
> OK, but then it should be obvious, and explicitly mentioning that in
> the doc string just makes it more confusing. Or am I missing
> something?
>
> > > . The doc string stated:
> > >
> > > If NOT-CURRENT, if the match is under point, it will not be
> > > returned, but instead the next instance is returned, if any.
> > >
> > > But the code, AFAIU, just checks whether the value of PROPERTY at
> > > point matches that of the found region, which doesn't necessarily
> > > mean point is part of the region, it could just mean there are two
> > > regions with matching values of PROPERTY, and point belongs to one
> > > of them. Right?
> >
> > I'm not sure I understand the question...
>
> The code doesn't seem to make sure point is inside the same region as
> the one found by the initial attempt, it just compares the values of
> PROPERTY at point and in the found region, and if they match, it looks
> for another region. Is that a correct description of what the code
> does when NOT-CURRENT is non-nil?
>
> If the description is correct, then the doc string doesn't describe
> what the code does accurately.
>
> > 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?
>
> > > . What is the reason for having VALUE an optional argument? Is it a
> > > frequent/useful operation to look for a VALUE of nil?
> >
> > If PREDICATE is nil, then having to use an explicit nil VALUE isn't
> > necessary.
>
> I don't understand how this answers my questions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 15:13:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > . The original doc string said about nil as PREDICATE:
>> >
>> > `nil' means almost the same as \"not equal\", but will also
>> > end the match if the value of PROPERTY changes.
>> >
>> > What does it mean to "end the match if the value changes"? The
>> > text went on to say "See the manual for extensive examples", but
>> > the manual doesn't mention this aspect of nil, it just says "not
>> > equal".
>>
>> If point is inside a region where PROPERTY has a non-nil value, using
>> nil as the predicate will end the search when PROPERTY changes value.
>
> OK, but then it should be obvious, and explicitly mentioning that in
> the doc string just makes it more confusing. Or am I missing
> something?
It's not obvious -- it's the difference between nil and a lambda that
just says (not (equal...)).
I think the manual needs those copious examples that I apparently forgot
to write.
It's probably easier to understand if you go to a buffer like this:
(defun text-property-setup ()
(insert "This is "
(propertize "bold1" 'face 'bold)
" and this is "
(propertize "italic1" 'face 'italic)
(propertize "bold2" 'face 'bold)
(propertize "italic2" 'face 'italic)
" at the end")
(goto-char (point-min)))
and see the difference between
(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.
>> > . The doc string stated:
>> >
>> > If NOT-CURRENT, if the match is under point, it will not be
>> > returned, but instead the next instance is returned, if any.
>> >
>> > But the code, AFAIU, just checks whether the value of PROPERTY at
>> > point matches that of the found region, which doesn't necessarily
>> > mean point is part of the region, it could just mean there are two
>> > regions with matching values of PROPERTY, and point belongs to one
>> > of them. Right?
>>
>> I'm not sure I understand the question...
>
> The code doesn't seem to make sure point is inside the same region as
> the one found by the initial attempt, it just compares the values of
> PROPERTY at point and in the found region, and if they match, it looks
> for another region. Is that a correct description of what the code
> does when NOT-CURRENT is non-nil?
Yes.
> If the description is correct, then the doc string doesn't describe
> what the code does accurately.
I think that's what the current doc string also says, but perhaps not
clearly enough.
>> 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.
>> > . What is the reason for having VALUE an optional argument? Is it a
>> > frequent/useful operation to look for a VALUE of nil?
>>
>> If PREDICATE is nil, then having to use an explicit nil VALUE isn't
>> necessary.
>
> 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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 15:14:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Please help me finish this job, thanks in advance.
Hey, that was 23 hours ago. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 15:14:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> In any case, the API uses double negation in the default case (find
> text whose value of PROPERTY does NOT match no-value), which is
> baaad...
Yes, it was a late addition, not part of the original design,
unfortunately...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 17:07:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: lekktu <at> gmail.com, 37488 <at> debbugs.gnu.org, michael_heerdegen <at> web.de
> Date: Thu, 26 Sep 2019 17:12:46 +0200
>
> (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))))
?
> >> > But the code, AFAIU, just checks whether the value of PROPERTY at
> >> > point matches that of the found region, which doesn't necessarily
> >> > mean point is part of the region, it could just mean there are two
> >> > regions with matching values of PROPERTY, and point belongs to one
> >> > of them. Right?
> >>
> >> I'm not sure I understand the question...
> >
> > The code doesn't seem to make sure point is inside the same region as
> > the one found by the initial attempt, it just compares the values of
> > PROPERTY at point and in the found region, and if they match, it looks
> > for another region. Is that a correct description of what the code
> > does when NOT-CURRENT is non-nil?
>
> Yes.
>
> > If the description is correct, then the doc string doesn't describe
> > what the code does accurately.
>
> I think that's what the current doc string also says, but perhaps not
> clearly enough.
>
> >> 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?
> >> > . What is the reason for having VALUE an optional argument? Is it a
> >> > frequent/useful operation to look for a VALUE of nil?
> >>
> >> If PREDICATE is nil, then having to use an explicit nil VALUE isn't
> >> necessary.
> >
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 19:17:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
>> >> 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".
>> >> > . What is the reason for having VALUE an optional argument? Is it a
>> >> > frequent/useful operation to look for a VALUE of nil?
>> >>
>> >> If PREDICATE is nil, then having to use an explicit nil VALUE isn't
>> >> necessary.
>> >
>> > 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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Thu, 26 Sep 2019 19:26:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael_heerdegen <at> web.de, lekktu <at> gmail.com, 37488 <at> debbugs.gnu.org
> Date: Thu, 26 Sep 2019 21:16:19 +0200
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Fri, 27 Sep 2019 14:16:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> 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).
No. Once again, you can test this behaviour with this simple code:
(insert "This is "
(propertize "bold1" 'face 'bold)
" and this is "
(propertize "italic1" 'face 'italic)
(propertize "bold2" 'face 'bold)
(propertize "italic2" 'face 'italic)
" at the end")
Put point inside the first bold text and see the difference between
(text-property-search-forward 'face 'bold t t)
(text-property-search-forward 'face 'bold t nil)
>> >> > 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.
That doesn't give you the region matched.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Fri, 27 Sep 2019 14:35:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael_heerdegen <at> web.de, lekktu <at> gmail.com, 37488 <at> debbugs.gnu.org
> Date: Fri, 27 Sep 2019 16:15:47 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > 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).
>
> No. Once again, you can test this behaviour with this simple code:
Would you please humor me, and explain how the code does that by
walking the code itself? I have problem understanding that from
examples, sorry for my limitations.
All I see is that the code calls text-property--match-p, and that one
just compares two values of the property. What am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Fri, 27 Sep 2019 14:38:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 37488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> All I see is that the code calls text-property--match-p, and that one
> just compares two values of the property. What am I missing?
I think the magic is in text-property--find-end-forward and -backward,
where the nil PREDICATE has special meaning.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37488; Package
emacs.
(Sat, 28 Sep 2019 14:46:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 37488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael_heerdegen <at> web.de, lekktu <at> gmail.com, 37488 <at> debbugs.gnu.org
> Date: Fri, 27 Sep 2019 16:36:57 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > All I see is that the code calls text-property--match-p, and that one
> > just compares two values of the property. What am I missing?
>
> I think the magic is in text-property--find-end-forward and -backward,
> where the nil PREDICATE has special meaning.
Thanks, I figured it out and updated the doc strings.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 27 Oct 2019 11:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 293 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.