GNU bug report logs -
#47564
text-property-search-forward does not behave as advertized
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 47564 in the body.
You can then email your comments to 47564 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#47564
; Package
emacs
.
(Fri, 02 Apr 2021 14:09:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nicolas Graner <nicolas <at> graner.name>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 02 Apr 2021 14:09:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I found some discrepancies between the behavior of
text-property-search-forward and text-property-search-backward, and what
the doc says they should do. I am not sure whether they are bugs or
documentation errors, except for the last one below which is clearly a
bug.
Here is how to reproduce starting from an empty buffer, tested on
28.0.50. I have inserted comments with my observations.
(insert "12345678")
(put-text-property 3 6 'foo 'bar)
(goto-char 1)
(text-property-search-forward 'foo 'bar t)
;; moves point to 6 and returns range 3 to 6
;; Doc says it should move the point to start of range, but it
;; consistently moves to end of range.
(goto-char 1)
(text-property-search-forward 'foo 'bar nil)
;; moves point to 3 and returns range 1 to 3, whre property foo is nil.
;; Doc says: with PREDICATE nil, a value will match if it is
;; non-nil and is NOT ‘equal’ to VALUE.
;; In fact, the condition "it is non-nil" is apparently ignored.
(goto-char 9)
(text-property-search-backward 'foo 'bar t)
;; moves point to 3 and returns range 3 to 6
;; As above, consistently moves to beginning of range instead of end.
(goto-char 7)
(text-property-search-backward 'foo 'bar t)
;; returns nil. This one is really weird, considering it works OK from
;; position 6 or 8. As if there was something special when you start 1
;; after the end of a range.
Hope this helps,
Nicolas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47564
; Package
emacs
.
(Sat, 10 Apr 2021 16:28:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 47564 <at> debbugs.gnu.org (full text, mbox):
Nicolas Graner <nicolas <at> graner.name> writes:
>
> (insert "12345678")
> (put-text-property 3 6 'foo 'bar)
> (goto-char 1)
> (text-property-search-forward 'foo 'bar t)
> ;; moves point to 6 and returns range 3 to 6
> ;; Doc says it should move the point to start of range, but it
> ;; consistently moves to end of range.
I see this was changed in
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b295174210465c4285729c67ec014e0f5b53f741,
but I don't know about the reasons for the change. In any case, the
docstring is now inconsistent with the documentation in the Elisp
manual, which says that point is placed at the end (which matches the
implementation). I've CC Stefan, but I think the docstring error is
that `text-property-search-forward' moves point to the end of the
matched region, and `text-property-search-backward' moves point to the
beginning of the matched region.
> (goto-char 1)
> (text-property-search-forward 'foo 'bar nil)
> ;; moves point to 3 and returns range 1 to 3, whre property foo is nil.
> ;; Doc says: with PREDICATE nil, a value will match if it is
> ;; non-nil and is NOT ‘equal’ to VALUE.
> ;; In fact, the condition "it is non-nil" is apparently ignored.
After reading the code, I'd say you're correct and the "non-nil" is
ignored in the implementation. This part was added in response to this
bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37488, perhaps
I'm missing something.
> (goto-char 9)
> (text-property-search-backward 'foo 'bar t)
> ;; moves point to 3 and returns range 3 to 6
> ;; As above, consistently moves to beginning of range instead of end.
I think this is the same documentation bug as the first one.
> (goto-char 7)
> (text-property-search-backward 'foo 'bar t)
> ;; returns nil. This one is really weird, considering it works OK from
> ;; position 6 or 8. As if there was something special when you start 1
> ;; after the end of a range.
Yes, this seems like an off-by-one error in the implementation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47564
; Package
emacs
.
(Wed, 29 Jun 2022 10:45:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 47564 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> Nicolas Graner <nicolas <at> graner.name> writes:
>> (insert "12345678")
>> (put-text-property 3 6 'foo 'bar)
>> (goto-char 1)
>> (text-property-search-forward 'foo 'bar t)
>> ;; moves point to 6 and returns range 3 to 6
>> ;; Doc says it should move the point to start of range, but it
>> ;; consistently moves to end of range.
>
> I see this was changed in
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b295174210465c4285729c67ec014e0f5b53f741,
> but I don't know about the reasons for the change. In any case, the
> docstring is now inconsistent with the documentation in the Elisp
> manual, which says that point is placed at the end (which matches the
> implementation). I've CC Stefan, but I think the docstring error is
> that `text-property-search-forward' moves point to the end of the
> matched region, and `text-property-search-backward' moves point to the
> beginning of the matched region.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Looking at the manual and the doc strings, they seem to be in agreement
on this point (in Emacs 29, at least).
>> (goto-char 1)
>> (text-property-search-forward 'foo 'bar nil)
>> ;; moves point to 3 and returns range 1 to 3, whre property foo is nil.
>> ;; Doc says: with PREDICATE nil, a value will match if it is
>> ;; non-nil and is NOT ‘equal’ to VALUE.
>> ;; In fact, the condition "it is non-nil" is apparently ignored.
>
> After reading the code, I'd say you're correct and the "non-nil" is
> ignored in the implementation. This part was added in response to this
> bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37488, perhaps
> I'm missing something.
I've re-re-rewritten the documentation here after that a while ago
(because most of the additions there weren't correct).
>> (goto-char 7)
>> (text-property-search-backward 'foo 'bar t)
>> ;; returns nil. This one is really weird, considering it works OK from
>> ;; position 6 or 8. As if there was something special when you start 1
>> ;; after the end of a range.
>
> Yes, this seems like an off-by-one error in the implementation.
Looks like this has been fixed in the meantime.
So I think that everything here has been fixed by now (at least in Emacs
29), so I'm closing this bug report. If any of these issues still
remain, please open a new bug report for those issues.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
47564 <at> debbugs.gnu.org and Nicolas Graner <nicolas <at> graner.name>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 29 Jun 2022 10:45:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 27 Jul 2022 11:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 274 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.