From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#58937: text-property-search-backward misses one-character regions Date: Thu, 03 Nov 2022 11:35:40 +0200 Message-ID: <835yfw8jo3.fsf@gnu.org> References: <87o7tpdix0.fsf@graner.name> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31113"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 58937-done@debbugs.gnu.org To: Nicolas Graner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 03 10:37:36 2022 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 1oqWfG-0007hi-Ga for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Nov 2022 10:37:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqWf8-0004if-BF; Thu, 03 Nov 2022 05:37:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqWel-0004Ib-Iy for bug-gnu-emacs@gnu.org; Thu, 03 Nov 2022 05:37:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oqWel-0004Qi-9H for bug-gnu-emacs@gnu.org; Thu, 03 Nov 2022 05:37:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqWel-0001Gm-3S for bug-gnu-emacs@gnu.org; Thu, 03 Nov 2022 05:37:03 -0400 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Nov 2022 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 58937 X-GNU-PR-Package: emacs Mail-Followup-To: 58937@debbugs.gnu.org, eliz@gnu.org, nicolas@graner.name Original-Received: via spool by 58937-done@debbugs.gnu.org id=D58937.16674681634774 (code D ref 58937); Thu, 03 Nov 2022 09:37:02 +0000 Original-Received: (at 58937-done) by debbugs.gnu.org; 3 Nov 2022 09:36:03 +0000 Original-Received: from localhost ([127.0.0.1]:48010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqWdn-0001Ev-G6 for submit@debbugs.gnu.org; Thu, 03 Nov 2022 05:36:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqWdi-0001EO-Ak for 58937-done@debbugs.gnu.org; Thu, 03 Nov 2022 05:36:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqWdZ-0004ET-Ps; Thu, 03 Nov 2022 05:35:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tbbPZN38MQh9i8Wj7bhls9uyEIgpisTGkGOqmmzXjJg=; b=gFMU0716s0lq4hvqLd5L 9SDwBq9fumnZcuM9TkptMMmWPaKelv8MX4foAERXJcYc7UU6rP6NIbINETzQCLkZGTWnvnX7G09Sy NyxqVOjOnnlLHioajuawPTGWg2MDogO9QP0fE1cYbLuEkQJkkwgHfQf3u62c7xhyqZQdL6crGRplm UUCKBX3UzuOJqcp17LhCaXrpfJwhCqW+GkJ0Br/rERmSty9bfavTvp1miqx6VYyej24uL9dDmeXUg ofiA5ebT5xmCcxjG0d9vuFDeGXxr/Lwi16V9ZVguSF42AAtTSE/9j9vDONNgOy7PqM1bGq8hPg9wX DZ55JV3zNXysOg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqWdY-00042x-3w; Thu, 03 Nov 2022 05:35:49 -0400 In-Reply-To: <87o7tpdix0.fsf@graner.name> (message from Nicolas Graner on Thu, 03 Nov 2022 00:40:43 +0100) 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: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246941 Archived-At: > From: Nicolas Graner > Cc: larsi@gnus.org, 58937@debbugs.gnu.org > Date: Thu, 03 Nov 2022 00:40:43 +0100 > > This works fine in all the cases I have tested, although I don't claim > to have tested all relevant combinations of arguments and region lengths > and positions... Thanks, I installed the change. > Here, the PREDICATE argument is a function, not the usual t or nil: > > (with-current-buffer (generate-new-buffer "test") > (insert "123456789") > (put-text-property 2 4 'foo "abcd") > (put-text-property 4 6 'foo "efgh") > (goto-char 1) > (text-property-search-forward 'foo 4 (lambda (l str) (= l (length str))))) ??? The documentation says PREDICATE is called with 2 arguments: the VALUE argument to text-property-search-forward and the actual value of the text property to examine. There's no property value of 4 in this example, so it sounds like you are (ab)using the feature in some way that we didn't really intend to support. More to the point, Emacs always considers segments of characters whose values of the same property are different as distinct segments. You seem to expect that Emacs would join these two segments because you supplied PREDICATE that returns t for both, but Emacs cannot do that, because the underlying text-property machinery doesn't even look at the next segment before it processes the first one. And no PREDICATE in this API can ever change that basic fact. So your expectations are incorrect, and cannot be met by this API, which specifically meant to examine the text segments one by one and subject each one of them to PREDICATE, separately. > The docstring for text-property-search-forward says: > If PREDICATE is nil (which is the default value), a value will > match if is not ‘equal’ to VALUE. Furthermore, a nil PREDICATE > means that the match region is ended if the value changes. > > This implies that when PREDICATE is not nil, the match region should not > end when the value changes, but only when the predicate is no longer > satisfied. Is this correct? No, it isn't. The region always ends where the property changes value, regardless of what PREDICATE thinks.