all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Howard Melman <hmelman@gmail.com>
Cc: 48317@debbugs.gnu.org
Subject: bug#48317: 27.1; text-property-search-forward moves point to end when not found
Date: Wed, 12 May 2021 18:55:59 +0200	[thread overview]
Message-ID: <87fsyrhoww.fsf@gnus.org> (raw)
In-Reply-To: <1A7FC13A-A462-4D59-A0C1-64761BDE12A5@gmail.com> (Howard Melman's message of "Wed, 12 May 2021 12:29:10 -0400")

Howard Melman <hmelman@gmail.com> writes:

> It's probably impossible to change in the signature because of
> compatibility but perhaps this could inform the docstring.  AIUI if
> this function is not passed a VALUE or PREDICATE it searches for
> regions that contain PROPERTY (a "trick" because a property having a
> nil value is the same as not being present).  But with just a VALUE it
> searches for areas that don't have the PROPERTY/VALUE combo because
> PREDICATE is nil.  And if PREDICATE is t it searches for areas that do
> have that combo.

I think you've gotten how the function works now.  :-)

Except that the nil PREDICATE isn't exactly the same as "not equal" --
in that case, all regions with the same value (that doesn't match) would
be one single match, but the nil PREDICATE also stops when the value
changes.

> Since in lisp a default optional argument is nil, I think the behavior
> with the default value of PREDICATE is reversed from what it should be
> for a function named "search". Particularly since it changes the sense
> of the function from when just PROPERTY is passed as opposed to when
> PROPERTY and VALUE are passed (right?).

The one parameter version is intuitive, while the two parameter version
isn't -- that's true.  And this certainly wasn't helped by the doc
string stating the opposite of how this function worked.  :-)

> Your example of using this function with a while loop definitely helps
> reveal its intended use.  Perhaps including one when passing VALUE to
> the function would help?

I think that's for the manual, which has copious examples and explains
all the bits.  (And has, as far as I can tell, not been corrected to be
wrong while I wasn't looking.  :-))

> I will happily commented on a proposed docstring if you post it here.
> I've not signed papers but do I have to for docstring contributions?

No, that's not necessary -- but is there anything that needs to be
clarified further?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2021-05-12 16:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-09 16:41 bug#48317: 27.1; text-property-search-forward moves point to end when not found Howard Melman
2021-05-09 17:07 ` Eli Zaretskii
     [not found]   ` <616F7732-ED83-40F0-A460-9298608EAD91@gmail.com>
2021-05-09 17:48     ` Eli Zaretskii
     [not found]       ` <8877DDB9-7D2B-4DCC-8374-EB8391134EAC@gmail.com>
2021-05-09 18:33         ` Eli Zaretskii
2021-05-09 19:48           ` Howard Melman
2021-05-10  9:05           ` Lars Ingebrigtsen
2021-05-10 13:06             ` Howard Melman
2021-05-11 12:32               ` Lars Ingebrigtsen
2021-05-11 12:48                 ` Eli Zaretskii
2021-05-11 13:14                   ` Lars Ingebrigtsen
2021-05-11 14:20                 ` Howard Melman
2021-05-11 16:36                   ` Lars Ingebrigtsen
2021-05-11 19:28                     ` Howard Melman
2021-05-11 23:18                       ` Stephen Berman
2021-05-12 14:16                       ` Lars Ingebrigtsen
2021-05-12 16:29                         ` Howard Melman
2021-05-12 16:55                           ` Lars Ingebrigtsen [this message]
     [not found]                             ` <5AA9C2CD-D20B-4B9D-83D6-9002E9396558@gmail.com>
2022-05-13 18:32                               ` Howard Melman
2022-05-14  2:19                                 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fsyrhoww.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=48317@debbugs.gnu.org \
    --cc=hmelman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.