From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs 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 Message-ID: <87fsyrhoww.fsf@gnus.org> References: <0ECAF0D9-7D8C-4BAA-AFFE-B76634BD0B28@gmail.com> <83o8dj7s48.fsf@gnu.org> <616F7732-ED83-40F0-A460-9298608EAD91@gmail.com> <83lf8n7q8d.fsf@gnu.org> <8877DDB9-7D2B-4DCC-8374-EB8391134EAC@gmail.com> <83fsyv7o4y.fsf@gnu.org> <87mtt3c62q.fsf@gnus.org> <4E8819BD-AA07-4870-8A90-98FB1F3D45E4@gmail.com> <87fsytpi1s.fsf@gnus.org> <53218944-7009-4BA7-AE3D-BF025EFD41AF@gmail.com> <87mtt1kz1j.fsf@gnus.org> <9D0AA29D-DE30-43D7-8109-84636A3D36F0@gmail.com> <878s4kjaug.fsf@gnus.org> <1A7FC13A-A462-4D59-A0C1-64761BDE12A5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37241"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 48317@debbugs.gnu.org To: Howard Melman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 12 18:57:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lgsAa-0009TL-B0 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 May 2021 18:57:12 +0200 Original-Received: from localhost ([::1]:50802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgsAY-0001sk-EI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 May 2021 12:57:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53502) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgsAQ-0001sa-7A for bug-gnu-emacs@gnu.org; Wed, 12 May 2021 12:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgsAP-0003dI-Tx for bug-gnu-emacs@gnu.org; Wed, 12 May 2021 12:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lgsAP-0001c0-PZ for bug-gnu-emacs@gnu.org; Wed, 12 May 2021 12:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 May 2021 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48317 X-GNU-PR-Package: emacs Original-Received: via spool by 48317-submit@debbugs.gnu.org id=B48317.16208385716131 (code B ref 48317); Wed, 12 May 2021 16:57:01 +0000 Original-Received: (at 48317) by debbugs.gnu.org; 12 May 2021 16:56:11 +0000 Original-Received: from localhost ([127.0.0.1]:40325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgs9a-0001ap-RB for submit@debbugs.gnu.org; Wed, 12 May 2021 12:56:11 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:60672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgs9Z-0001aa-B6 for 48317@debbugs.gnu.org; Wed, 12 May 2021 12:56:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lWxx3zBLlraeLRLD7KjBCp8g7COD2RQK+5xbvZoED4s=; b=nepBCVoZxNulOfoxTJBQ9Tjpjn pI43Inf53By3R5u+VtNrr3nRUmehpB3FUEFFV/XiGkzPqmFZMde8xzebDu+Codu5zn4lIYYhcC6z3 lwB+tsD42vhC8fwBK1r0BoHJtXKAQ5ZKVCqUiyN9o8g1VZd12wI+b6TTBy7a8vHzd1qc=; Original-Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lgs9Q-0006tE-Cn; Wed, 12 May 2021 18:56:02 +0200 X-Now-Playing: Tuxedomoon's _Live in Alberobello, Italy_: "Dizzy" In-Reply-To: <1A7FC13A-A462-4D59-A0C1-64761BDE12A5@gmail.com> (Howard Melman's message of "Wed, 12 May 2021 12:29:10 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:206353 Archived-At: Howard Melman 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