From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Howard Melman Newsgroups: gmane.emacs.bugs Subject: bug#48317: 27.1; text-property-search-forward moves point to end when not found Date: Tue, 11 May 2021 15:28:48 -0400 Message-ID: <9D0AA29D-DE30-43D7-8109-84636A3D36F0@gmail.com> 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> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27093"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48317@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 11 21:29:19 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 1lgY4E-0006w1-Ps for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 May 2021 21:29:18 +0200 Original-Received: from localhost ([::1]:36566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgY4D-0000Pb-Ou for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 May 2021 15:29:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgY3z-0000HJ-VF for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 15:29:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54153) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgY3z-00012I-ML for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 15:29:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lgY3y-0001cf-Iu for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 15:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Howard Melman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 May 2021 19:29:02 +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.16207613376226 (code B ref 48317); Tue, 11 May 2021 19:29:02 +0000 Original-Received: (at 48317) by debbugs.gnu.org; 11 May 2021 19:28:57 +0000 Original-Received: from localhost ([127.0.0.1]:37466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgY3s-0001cM-Ot for submit@debbugs.gnu.org; Tue, 11 May 2021 15:28:57 -0400 Original-Received: from mail-qk1-f174.google.com ([209.85.222.174]:40599) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgY3r-0001c7-3U for 48317@debbugs.gnu.org; Tue, 11 May 2021 15:28:56 -0400 Original-Received: by mail-qk1-f174.google.com with SMTP id q136so19922400qka.7 for <48317@debbugs.gnu.org>; Tue, 11 May 2021 12:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t+ziCaBvvlCulswqpvVe5LTvrJ+nxvNesUnNspLECHI=; b=QvhQOdQGJYi8wRCf1MencdD2jCOLa81r6QHdVdygFYxqZtyrspLPfBRj7keDtVJ1hm awNQDuPnYgXHRzKpVL52Y9xsEhi7mocv+p/Np80/4jRcztUCI1/pC+BZCobTHlpK5r2r 3XCTAzOhHSqs4oE5gMFjHf3+p44XroRyL0Aw1/Skao3Rm2dXWfCYPJf8HsFCivwPfGaR sfj7gQe+2VUkVAypO1vtL+rO9gCoV3lc0m9WGHEmIBuQg7qcDx73G6bGQuI/I3DCkPDK WfGN3r0IDjAR10CvPE02szo/j6mY4me9dG52HZMTzySOwY9LUtgLPKYgHndOGVdNUBGz XIFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t+ziCaBvvlCulswqpvVe5LTvrJ+nxvNesUnNspLECHI=; b=fGB9ck9iw6DC/Xg54Zivdz2kzLHrVVbqguhdFJU0r/iw2zWgkCEw2hfGCNy9vjS+mc 7O3YXaj+HFsG63/dpoOeLoEtSi5bI3v7GGgL624Y0LuCfeZCpFCU7YmdMCZlwCzs0pUB OwnCCmriVKHXDBLDpmcIb82N0tnBcW25HZyz8+oRG65wJOAx2K3SFf6vRXIsYZsm1qiq y08P3fmeFVJw+GrBOIE6B1elOhteJPAGkYmR0QipNJrYo6p+z/HhawuWCVCtTt85alSK 0ZbUC1/l/QGORIfL7dlkMK5+qyDYNCgjOf6w5XrQl++4bOM8Z9MYvxRz7zWIt7AA6+2v KJ2A== X-Gm-Message-State: AOAM533ZYBVcwNIaay1ecEAkw+ATaSflAmU173r3TDDREmGP6o2ySFDG Hnewa8b26BBdFhEZr0bfoYKlqzijQ0k= X-Google-Smtp-Source: ABdhPJzywznmnbEQepr3IylhIk6Qpvse2NqvVuqzTpcXNXMMGAK/KR1J1BkBbmqeo3H6pJTKSuJQXQ== X-Received: by 2002:a05:620a:14b5:: with SMTP id x21mr29684496qkj.298.1620761329223; Tue, 11 May 2021 12:28:49 -0700 (PDT) Original-Received: from lumet2.home (pool-108-26-204-101.bstnma.fios.verizon.net. [108.26.204.101]) by smtp.gmail.com with ESMTPSA id y4sm14573099qti.53.2021.05.11.12.28.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 May 2021 12:28:48 -0700 (PDT) In-Reply-To: <87mtt1kz1j.fsf@gnus.org> X-Mailer: Apple Mail (2.3608.120.23.2.6) 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:206280 Archived-At: On May 11, 2021, at 12:36 PM, Lars Ingebrigtsen wrote: >=20 > Howard Melman writes: >=20 >>> I'm sorry, I don't follow you. It this still about >>>=20 >>> (text-property-search-forward 'facet 'foo) >>>=20 >>> ? That works as designed, as far as I can tell. (But not as = documented >>> in the Emacs 27.1 doc string.) >>=20 >> Yes, Note that says "facet" and not "face" >=20 > Yes, that the text property you're looking for is called `facet'? >=20 >> To be more clear, I find when calling: >>=20 >> (text-property-search-forward 'unused-property 'my-package-face) >>=20 >> when no text in the buffer has the property unused-property, that >> calling text-property-search-forward moves point to eob. >>=20 >> Is this intended behavior? If so I don't understand why.=20 >=20 > I'm not sure I understand what you're not understanding. :-) =20 I have felt the same way :) Thanks for your patience. > You're using nil as the PREDICATE here (a missing parameter is nil), = which > means that you're searching for areas in the buffer where the text > property `facet' is not equal to `foo'. Which is the rest of the = buffer. Thank you for explaining the logic and not just saying "working as = designed". "Which is the rest of the buffer." is what clicked for me. I was reading "text-property-search-forward" as "look forward to find a text property PROPERTY with value VALUE." There wasn't one, so the search should should fail and not move point. =20 To me, this function behaves unexpectedly different in these cases (say in a font-locked elisp buffer just before the last defun): ;; a region with property face is found, ;; point is moved to the end of it (text-property-search-forward 'face) ;; a region with property unused is not found, ;; point is unmoved (text-property-search-forward 'unused) ;; a region with the specfied face is found, ;; point is moved to the beginning of it (text-property-search-forward 'face 'font-lock-function-name-face) ;; a region with the specfied face is not found, ;; point is moved to eob (text-property-search-forward 'face 'unused) ;; a region with the specfied property is not found, ;; point is moved to eob (text-property-search-forward 'unused-prop 'unused-value) The first two behave perfectly reasonably to me. And as the manual suggests, behaves the same as search-forward. The 3rd does as well, of course. I'd expect both the 4th and the 5th to behave the same as the 2nd but they move point to eob. And while I now mostly understand (but don't fully grok) the logic, it's baffling to me that to make the last three behave like the first two I should set PREDICATE to t (and btw doing so changes the behavior of the 3rd to leave point at the end of the match instead of the beginning, which seems odd). The difference between the 3rd and 4th isn't some subtle difference between using equal and eq or something, it's that the specified value of the face is not found as it was using the default predicate in the 3rd case. And particularly in the 5th, the choice of predicate to evaluate 'unused-value shouldn't come into play because 'unused-prop itself isn't found. And the documentation describing PREDICATE nil didn't help me at all. In the manual it says for nil: (which means =E2=80=9Cnot equal=E2=80=9D) which sounds to me as if it is using the function not. =20 And in your updated docstring as: a value will match if is not `equal' to VALUE which really throws me because the 3rd case above works and it's=20 not "not `equal'" to font-lock-function-name-face! Does this explain my confusion? I interpret all of these: (search-forward "defun") (text-property-search-forward 'face) (text-property-search-forward 'face 'font-lock-function-name-face) to mean search for the thing I specified, whether that's a string, a specific property with any value or a specific property with a specific value. But somehow the last one is different. And try as I might now to write how it's being interpreted I'm unable to. Search for the property face but only if it is font-lock-function-name-face or if it isn't...? Howard