From unknown Sun Aug 17 01:43:39 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#57150 <57150@debbugs.gnu.org> To: bug#57150 <57150@debbugs.gnu.org> Subject: Status: 29.0.50; [PATCH] Add test coverage for overlay modification hooks Reply-To: bug#57150 <57150@debbugs.gnu.org> Date: Sun, 17 Aug 2025 08:43:39 +0000 retitle 57150 29.0.50; [PATCH] Add test coverage for overlay modification h= ooks reassign 57150 emacs submitter 57150 Matt Armstrong severity 57150 normal tag 57150 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 00:33:18 2022 Received: (at submit) by debbugs.gnu.org; 12 Aug 2022 04:33:18 +0000 Received: from localhost ([127.0.0.1]:55323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMMMH-0004rb-JS for submit@debbugs.gnu.org; Fri, 12 Aug 2022 00:33:17 -0400 Received: from lists.gnu.org ([209.51.188.17]:38612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMMME-0004rT-VV for submit@debbugs.gnu.org; Fri, 12 Aug 2022 00:33:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMMLs-0003qy-Q1 for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 00:33:05 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:39187) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMMLp-00049Y-HZ for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 00:32:51 -0400 Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id AA38EFF802 for ; Fri, 12 Aug 2022 04:32:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1660278765; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=b89JfyotsG24uElfTDtKusO9vFm5Xl4zId22Aal5b8A=; b=Bkkt0dRpyz3QaJKKoaTA+yqX4FtgZmDFjjdFXnz3JYOgCLbPBWeRi8+Kqj1nqFrGOuJc8p 1cw0JH9MFHP7wtvf6cSUIQR/jtFodde/8yFVKd3wrF6vBfzv7nCqBDFkCq208KlNxHofni tCXcIfljVxP2JfQQVIW+jhpYrQc0KochlkytkpSJQUwKmoNHVmyLj6sgIRd182KdJfWkJ5 E828qiuBJ4dKllidtC4aIZ+VWf2lBnnf+NgbGqKWTJ8Yc4Qcqov0GDLI8hoKaDi5QlwW6j G4uC07pu1bD9dAuSdnrGh+LJqsnrM/u7evzxzY/jdQDEEOlys08CgfVaCMg44A== Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1oMMLg-0009lF-2E for bug-gnu-emacs@gnu.org; Thu, 11 Aug 2022 21:32:40 -0700 From: Matt Armstrong To: bug-gnu-emacs@gnu.org Subject: 29.0.50; [PATCH] Add test coverage for overlay modification hooks Date: Thu, 11 Aug 2022 21:32:40 -0700 Message-ID: <87ilmygjyv.fsf@rfc20.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=217.70.183.199; envelope-from=matt@rfc20.org; helo=relay9-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain I noticed there was no explicit test against the overlay modification hook boundary conditions. The attached patch adds some, which might be nice to have if a person (possibly me) someday optimizes overlay performance with a change in data structure. In writing this I was surprised to learn that the hooks do not behave differently if the overlay is `front-advance' or `rear-advance', so this is explicitly tested. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Add-test-coverage-for-overlay-modification-hooks.patch >From 9083709cbe12ab97b795bcac8343f9d11f2929b7 Mon Sep 17 00:00:00 2001 From: Matt Armstrong Date: Thu, 11 Aug 2022 21:11:36 -0700 Subject: [PATCH] Add test coverage for overlay modification hooks * test/src/buffer-tests.el: (overlay-modification-hooks) new ert-deftest. --- test/src/buffer-tests.el | 66 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/test/src/buffer-tests.el b/test/src/buffer-tests.el index 3c6a9208ff..ee25b43f9e 100644 --- a/test/src/buffer-tests.el +++ b/test/src/buffer-tests.el @@ -22,6 +22,72 @@ (require 'ert) (require 'ert-x) (require 'cl-lib) +(require 'pcase) + +(ert-deftest overlay-modification-hooks () + "Test the `modification-hooks' overlay property. + +This also tests `insert-in-front-hooks' and `insert-behind-hooks'." + ;; Perform operation against the given needle (a position or string) + ;; and expect the `modification-hook', `insert-in-front-hooks' and + ;; `insert-behind-hooks' to be called with the given arguments. All + ;; tests are performed against the same fixed buffer and overlay. + (pcase-dolist (`(,operation + ,needle + ,expected-insert-in-front-calls + ,expected-modification-calls + ,expected-insert-behind-calls) + '((insert 1 nil nil nil) + (insert 2 ((nil 2 2) (t 2 3 0)) nil nil) + (insert 3 nil ((nil 3 3) (t 3 4 0)) nil) + (insert 4 nil nil ((nil 4 4) (t 4 5 0))) + (insert 5 nil nil nil) + (replace "1" nil nil nil) + (replace "2" nil ((nil 2 3) (t 2 3 1)) nil) + (replace "3" nil ((nil 3 4) (t 3 4 1)) nil) + (replace "4" nil nil nil) + (replace "12" nil ((nil 1 3) (t 1 2 2)) nil) + (replace "23" nil ((nil 2 4) (t 2 3 2)) nil) + (replace "34" nil ((nil 3 5) (t 3 4 2)) nil) + (replace "123" nil ((nil 1 4) (t 1 2 3)) nil) + (replace "234" nil ((nil 2 5) (t 2 3 3)) nil) + (replace "1234" nil ((nil 1 5) (t 1 2 4)) nil))) + ;; All three hooks ignore the overlay's `front-advance' and + ;; `rear-advance' option, so test ways and expect the same result. + (dolist (advance '(nil t)) + (with-temp-buffer + (insert "1234") + (let (modification-calls insert-in-front-calls insert-behind-calls + (overlay (make-overlay 2 4 nil advance advance))) + (overlay-put overlay + 'modification-hooks + (list (lambda (ov &rest args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push args modification-calls)))) + (overlay-put overlay + 'insert-in-front-hooks + (list (lambda (ov &rest args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push args insert-in-front-calls)))) + (overlay-put overlay + 'insert-behind-hooks + (list (lambda (ov &rest args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push args insert-behind-calls)))) + (pcase-exhaustive operation + (`insert (goto-char needle) + (insert "x")) + (`replace (goto-char (point-min)) + (replace-string needle "x"))) + (should (equal (reverse insert-in-front-calls) + expected-insert-in-front-calls)) + (should (equal (reverse modification-calls) + expected-modification-calls)) + (should (equal (reverse insert-behind-calls) + expected-insert-behind-calls))))))) (ert-deftest overlay-modification-hooks-message-other-buf () "Test for bug#21824. -- 2.35.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 00:41:34 2022 Received: (at 57150) by debbugs.gnu.org; 12 Aug 2022 04:41:34 +0000 Received: from localhost ([127.0.0.1]:55329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMMUH-000542-Mt for submit@debbugs.gnu.org; Fri, 12 Aug 2022 00:41:34 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:46401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMMUE-00053l-JY for 57150@debbugs.gnu.org; Fri, 12 Aug 2022 00:41:32 -0400 Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id F185C200004 for <57150@debbugs.gnu.org>; Fri, 12 Aug 2022 04:41:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1660279284; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jI/hAu0/mkRFage4cpb+FvdeNd8aqXXbZ35apflFynA=; b=dcDyflshlb30uXOcMd+2RKdMWfG52xTjuaxdn3BTyLEOm64f6wzEzrk/6pQxH9LUbMahmZ ZpFOFnwfEkZ0sYADpQbS7G8h4RVnHzpuZo1I/CVxylzQqHKuM51QH0tFD2xx36tKjTGTQv FRenz+VGjvuXIMVozhTQZeLpUeIv5RfNAPECBeqqTC3nxIKYONSKBl/GLNsriZotFyLzwI yAM+CMKLODst7Jzukh+nY4WxmnRI0NzHhFMxF8vGJBzrxYutEILamxU4MwnAnxY1KqR6Up msKNamnq1ptm2nvkMupdGg0IMdsUiRo+clyxDh/LYEZn5KRQJTGFVABtYp6SJA== Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1oMMU5-0009yE-2b for 57150@debbugs.gnu.org; Thu, 11 Aug 2022 21:41:21 -0700 From: Matt Armstrong To: 57150@debbugs.gnu.org Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <87ilmygjyv.fsf@rfc20.org> (Matt Armstrong's message of "Thu, 11 Aug 2022 21:32:40 -0700") References: <87ilmygjyv.fsf@rfc20.org> Date: Thu, 11 Aug 2022 21:41:21 -0700 Message-ID: <87edxmgjke.fsf@rfc20.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57150 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Matt Armstrong writes: > I noticed there was no explicit test against the overlay modification > hook boundary conditions. The attached patch adds some, which might > be nice to have if a person (possibly me) someday optimizes overlay > performance with a change in data structure. > > In writing this I was surprised to learn that the hooks do not behave > differently if the overlay is `front-advance' or `rear-advance', so > this is explicitly tested. ...follow up with a comment typo fix. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Add-test-coverage-for-overlay-modification-hooks.patch >From 372c894e8d33eb5271b6c19b2e2e2843197a7353 Mon Sep 17 00:00:00 2001 From: Matt Armstrong Date: Thu, 11 Aug 2022 21:11:36 -0700 Subject: [PATCH] Add test coverage for overlay modification hooks * test/src/buffer-tests.el: (overlay-modification-hooks) new ert-deftest. --- test/src/buffer-tests.el | 67 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/test/src/buffer-tests.el b/test/src/buffer-tests.el index 3c6a9208ff..381d8618aa 100644 --- a/test/src/buffer-tests.el +++ b/test/src/buffer-tests.el @@ -22,6 +22,73 @@ (require 'ert) (require 'ert-x) (require 'cl-lib) +(require 'pcase) + +(ert-deftest overlay-modification-hooks () + "Test the `modification-hooks' overlay property. + +This also tests `insert-in-front-hooks' and `insert-behind-hooks'." + ;; Perform operation against the given needle (a position or string) + ;; and expect the `modification-hook', `insert-in-front-hooks' and + ;; `insert-behind-hooks' to be called with the given arguments. All + ;; tests are performed against the same fixed buffer and overlay. + (pcase-dolist (`(,operation + ,needle + ,expected-insert-in-front-calls + ,expected-modification-calls + ,expected-insert-behind-calls) + '((insert 1 nil nil nil) + (insert 2 ((nil 2 2) (t 2 3 0)) nil nil) + (insert 3 nil ((nil 3 3) (t 3 4 0)) nil) + (insert 4 nil nil ((nil 4 4) (t 4 5 0))) + (insert 5 nil nil nil) + (replace "1" nil nil nil) + (replace "2" nil ((nil 2 3) (t 2 3 1)) nil) + (replace "3" nil ((nil 3 4) (t 3 4 1)) nil) + (replace "4" nil nil nil) + (replace "12" nil ((nil 1 3) (t 1 2 2)) nil) + (replace "23" nil ((nil 2 4) (t 2 3 2)) nil) + (replace "34" nil ((nil 3 5) (t 3 4 2)) nil) + (replace "123" nil ((nil 1 4) (t 1 2 3)) nil) + (replace "234" nil ((nil 2 5) (t 2 3 3)) nil) + (replace "1234" nil ((nil 1 5) (t 1 2 4)) nil))) + ;; All three hooks ignore the overlay's `front-advance' and + ;; `rear-advance' option, so test both ways and expect the same + ;; result. + (dolist (advance '(nil t)) + (with-temp-buffer + (insert "1234") + (let (modification-calls insert-in-front-calls insert-behind-calls + (overlay (make-overlay 2 4 nil advance advance))) + (overlay-put overlay + 'modification-hooks + (list (lambda (ov &rest args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push args modification-calls)))) + (overlay-put overlay + 'insert-in-front-hooks + (list (lambda (ov &rest args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push args insert-in-front-calls)))) + (overlay-put overlay + 'insert-behind-hooks + (list (lambda (ov &rest args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push args insert-behind-calls)))) + (pcase-exhaustive operation + (`insert (goto-char needle) + (insert "x")) + (`replace (goto-char (point-min)) + (replace-string needle "x"))) + (should (equal (reverse insert-in-front-calls) + expected-insert-in-front-calls)) + (should (equal (reverse modification-calls) + expected-modification-calls)) + (should (equal (reverse insert-behind-calls) + expected-insert-behind-calls))))))) (ert-deftest overlay-modification-hooks-message-other-buf () "Test for bug#21824. -- 2.35.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 02:20:17 2022 Received: (at 57150) by debbugs.gnu.org; 12 Aug 2022 06:20:17 +0000 Received: from localhost ([127.0.0.1]:55451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMO1n-0007u2-Tf for submit@debbugs.gnu.org; Fri, 12 Aug 2022 02:20:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMO1j-0007ti-GN for 57150@debbugs.gnu.org; Fri, 12 Aug 2022 02:20:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40664) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMO1c-00025O-2b; Fri, 12 Aug 2022 02:20:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=N9LSFsRr1oIClaZ6eFFcYfLwMWqY6NvPJJj9gF4/tlM=; b=OMtnhWkzTexV NL1kQVIYCo8onqjxkTMfuwpSie+3SmwXxRat7bjDgcHZKHGy/wg+4W8/ASSWSqnkx4LAT7GlyzIWk 0AzxC4fIePoIY/LGJp7LBHGXArpf4w3JBGv+QlaZiy63gYzWZwFjlm1+5P0PeBQo1l90b9g7T95iS /GiEbhT7IM+QyoLp0NmEolFsG/nRo2kpx3r8FP5cjORQQK+EBigNcpLDOhuhXXWJSWKmjNLUgBLgE 5WcfvDFPv1P+EQGDa9yaqJi9b+l5LNmiJeHSVp0tQ7fxmXa5j/Onapfi+4CarvUkbajWX1Q1JgKRV vXorgMA8FMNbGwrRXQ9ooQ==; Received: from [87.69.77.57] (port=2117 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 1oMO1b-0000BT-HF; Fri, 12 Aug 2022 02:20:03 -0400 Date: Fri, 12 Aug 2022 09:19:59 +0300 Message-Id: <83o7wqnfu8.fsf@gnu.org> From: Eli Zaretskii To: Matt Armstrong In-Reply-To: <87edxmgjke.fsf@rfc20.org> (message from Matt Armstrong on Thu, 11 Aug 2022 21:41:21 -0700) Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks References: <87ilmygjyv.fsf@rfc20.org> <87edxmgjke.fsf@rfc20.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Matt Armstrong > Date: Thu, 11 Aug 2022 21:41:21 -0700 > > Matt Armstrong writes: > > > I noticed there was no explicit test against the overlay modification > > hook boundary conditions. The attached patch adds some, which might > > be nice to have if a person (possibly me) someday optimizes overlay > > performance with a change in data structure. > > > > In writing this I was surprised to learn that the hooks do not behave > > differently if the overlay is `front-advance' or `rear-advance', so > > this is explicitly tested. > > ...follow up with a comment typo fix. Thanks! Adding tests is always welcome, so this is fine, of course. Please allow me a few minor comments, though. A frequent gripe of mine about our test-suite tests is that the ideas of the tests are not sufficiently explained, where they aren't 110% obvious. The ERT framework and the tests themselves being highly macro-ized don't help in that matter, either. So please try to explain the idea of the tests and the details of the data structures as much as is reasonably possible. In this case: > +This also tests `insert-in-front-hooks' and `insert-behind-hooks'." > + ;; Perform operation against the given needle (a position or string) > + ;; and expect the `modification-hook', `insert-in-front-hooks' and > + ;; `insert-behind-hooks' to be called with the given arguments. All > + ;; tests are performed against the same fixed buffer and overlay. This is good, but it still lacks some details. First, "tests are performed against the same fixed buffer and overlay" is AFAIU inaccurate: pcase-dolist will create a new temporary buffer and a new overlay for each test. I guess the "all tests" part needs some qualification? Next, the names of the data structure elements, viz.: > + (pcase-dolist (`(,operation > + ,needle > + ,expected-insert-in-front-calls > + ,expected-modification-calls > + ,expected-insert-behind-calls) are quite descriptive, but then one sees stuff like this: > + (insert 2 ((nil 2 2) (t 2 3 0)) nil nil) > + (insert 3 nil ((nil 3 3) (t 3 4 0)) nil) > + (insert 4 nil nil ((nil 4 4) (t 4 5 0))) and wonders what's the semantics and meanings of the elements of the expected-* members that aren't atoms. I don't see this explained anywhere. > + (overlay (make-overlay 2 4 nil advance advance))) This means you don't test so-called "empty" overlays, whose START and END are identical. They are handled specially by the low-level support code. Maybe add more tests for that? Finally -- and that is another gripe of mine wrt our test suite -- when one of the tests fails, it is many times very hard to understand which code failed, because there are almost no unique identifiers of each 'should' or 'should-not' that are tested, and also because ERT runs the tests in the order that is different from the code order. The failure message shows the failing condition, which is good, but due to highly macro-ized form of the code, it is many times very hard to correlate the form that failed with the actual code, especially since our tests tend to have very similar forms in different tests of the same test source file. So please also think about this issue, and see if there's any way of making the failing tests tell more explicitly which part failed. E.g., maybe each member in your test data structure should have a unique ID (a name or an ordinal number), which could then be used in a way that would display that ID with the failure message. Or something. P.S. I do indeed hope that we merge the branch with the faster implementation of overlays some time soon, as overlays seem more and more as a significant slowdown factor in Emacs. Thanks again for working on this. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 13:57:18 2022 Received: (at 57150) by debbugs.gnu.org; 12 Aug 2022 17:57:19 +0000 Received: from localhost ([127.0.0.1]:58890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMYuM-0001xB-Cy for submit@debbugs.gnu.org; Fri, 12 Aug 2022 13:57:18 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:49855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMYuK-0001wx-G0 for 57150@debbugs.gnu.org; Fri, 12 Aug 2022 13:57:17 -0400 Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 5464FC0003; Fri, 12 Aug 2022 17:57:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1660327030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sRIBly5bB7NEEmAZGVSsEb0CtBIvRFD75PXZYlyxs/0=; b=Y+y6IqmO/Df7rhEDu8nzNCD0zAExdTMDuL9VFirLlB9lFAjfxWmqoB4kJBpbXD8miMm8zn CWI2+JFVXqMzmOcIcgUlJztYgZ62NCuvYiKhRXsBKoctnXt+d1IqJA6f21qBL4ZwokGiIH pzs5u3ctuyfjTwKAIyzlhr5fLSaa1PEu1BvjAbNuSi3gkcX1UMm9DkCXZIoK4Z6lkMCNoo fvwYW1FKbLZEufH8xrUDI5SmKPJZFpe4shtcZLEaczvGEfbt/VPwSvlLjbKdZkTJ+PJ+vG wbHmJhhpHdC9vcpgc71rgHq2vxMcKHXfgVEXrZMAFBjnXzkGeAgUPQvr+2a/xQ== Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1oMYuB-000Fuu-0X; Fri, 12 Aug 2022 10:57:07 -0700 From: Matt Armstrong To: Eli Zaretskii Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <83o7wqnfu8.fsf@gnu.org> References: <87ilmygjyv.fsf@rfc20.org> <87edxmgjke.fsf@rfc20.org> <83o7wqnfu8.fsf@gnu.org> Date: Fri, 12 Aug 2022 10:57:07 -0700 Message-ID: <874jyhgxak.fsf@rfc20.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > A frequent gripe of mine about our test-suite tests is that the ideas > of the tests are not sufficiently explained, where they aren't 110% > obvious. I enthusiastically agree. I will work on making these tests more clear. First I'd like your opinion on a few general questions. [...] > So please also think about this issue, and see if there's any way of > making the failing tests tell more explicitly which part failed. > E.g., maybe each member in your test data structure should have a > unique ID (a name or an ordinal number), which could then be used in a > way that would display that ID with the failure message. Or > something. Two specific questions: Do you have a preference between the two general approaches to exercising many similar test cases: data driven vs. macro driven? If data driven tests are preferred, what do you think of using 'message' to log the individual test case details, as a way of knowing which part failed? I usually favor data driven tests. With this approach, everything can often be expressed in a single function. Short of that, the usual lisp constructs can be composed in simple ways (regular functions, lambdas, etc). I usually don't like macro driven test case generation because the pattern often obscures the connection between the inputs and the test case logic and expected results. Turning to your specific question about ways of "making the failing tests tell more explicitly which part failed". Other test frameworks have scoped based context messages. In pseudocode, something like: (ert-deftest example () (dolist arg '(a b c d) (context (arg) (should (equal arg (identity-function arg)))))) Printed failures would include both the normal 'should' output, but also the values passed to 'context'. I notice that ERT does have two interactive features that partially address this. These commands are available in its UI: =E2=80=98l=E2=80=99 Show the list of =E2=80=98should=E2=80=99 forms executed in the test (=E2=80=98ert-results-pop-to-should-forms-for-test-at-point=E2=80=99). =E2=80=98m=E2=80=99 Show any messages that were generated (with the Lisp function =E2=80=98message=E2=80=99) in a test or any of the code that it invoked (=E2=80=98ert-results-pop-to-messages-for-test-at-point=E2=80=99). In simpler tests I find that 'l' is enough, since I can count the 'should' calls to work out the iteration of whatever loop is used by the test. In more complex cases, perhaps using 'message' to display the context is enough? If you don't think 'l' and 'm' are *not* good enough, I might agree with you. If you think adding something like 'context' to ERT is worthwhile I can look at doing that. For this patch, perhaps using 'message' is best? In the case of the macro-generated tests in buffer-tests.el I think they are too complex. For example: (deftest-make-overlay-1 A (1 1)) expands to: (ert-deftest buffer-tests--make-overlay-1-A nil (with-temp-buffer (should (make-overlay 1 1)))) I see two clear disadvantages to the macro. First, if ERT reports that 'buffer-tests--make-overlay-1-A' fails it isn't obvious where that specific test is defined in code. The next person coming along cannot simply search for "buffer-tests--make-overlay-1-A". Second, it is not clear what 'deftest-make-overlay-1' does. In this case, the test cases are defined 150 lines away from where the macro is defined. Compare the two approaches: (deftest-make-overlay-1 A (1 1)) (deftest-make-overlay-1 B (7 26)) (deftest-make-overlay-1 C (29 7)) (deftest-make-overlay-1 D (most-positive-fixnum 1)) (deftest-make-overlay-1 E (most-negative-fixnum 1)) (deftest-make-overlay-1 F (1 most-positive-fixnum)) (deftest-make-overlay-1 G (1 most-negative-fixnum)) (deftest-make-overlay-1 H (1 1 nil t)) (deftest-make-overlay-1 I (1 1 nil nil)) (deftest-make-overlay-1 J (1 1 nil nil nil)) (deftest-make-overlay-1 K (1 1 nil nil t)) (deftest-make-overlay-1 L (1 1 nil t t)) (deftest-make-overlay-1 M (1 1 nil "yes" "yes")) (ert-deftest make-overlay-success-cases () (dolist (args '((1 1) (7 26) (29 7) (most-positive-fixnum 1) (most-negative-fixnum 1) (1 most-positive-fixnum) (1 most-negative-fixnum) (1 1 nil t) (1 1 nil nil) (1 1 nil nil nil) (1 1 nil nil t) (1 1 nil t t) (1 1 nil "yes" "yes"))) (message "Testing %s" (cons 'make-overlay args)) (with-temp-buffer (should (funcall #'make-overlay args))))) If you think the second form is clearer I can work on that transformation (or not, but still avoid macro-generated tests in new code). > P.S. I do indeed hope that we merge the branch with the faster > implementation of overlays some time soon, as overlays seem more and > more as a significant slowdown factor in Emacs. > > Thanks again for working on this. It is slow going! From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 14:53:33 2022 Received: (at 57150) by debbugs.gnu.org; 12 Aug 2022 18:53:33 +0000 Received: from localhost ([127.0.0.1]:58922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMZmm-0003MJ-VP for submit@debbugs.gnu.org; Fri, 12 Aug 2022 14:53:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMZml-0003M5-9y for 57150@debbugs.gnu.org; Fri, 12 Aug 2022 14:53:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMZmf-0004Zs-Ji; Fri, 12 Aug 2022 14:53:25 -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=kqOrEoixyLHEZSCE6pwB46H8okEbOoj0KdeeAHToN7c=; b=GXVPujxxbHtjJ8Rnt2Ki tkxz9OAP3b/v8MaTa/lxc8BVBkl28zYl3XhL2RP6xsrOJPq6BGY8SOCMgvbZItN7uU+lQ1yY0R+Ij TFyeN32e01krDUVXXML+Eq+ro5ClX/XWeuKsbqrulD/ERHuZQrbz1rQeA4n2UqnrTHKs61zMzTXix 4SKznPWn1iZ35E9lu9eKv6L/FNc7uMTwVeFtDEGFRwrpgMW2KK4COEIOOBhuwYvZUd6LlcYVP7Ai0 OiwJDgMDHLS/EMAEHDygBwbuBjUyZQoPYELeERjs8m7bui7K2EJSDwjx2iyZZH1GJGT8kqdW5mEAS P6PoiR0FxoXjhA==; Received: from [87.69.77.57] (port=4465 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 1oMZmf-0007HC-27; Fri, 12 Aug 2022 14:53:25 -0400 Date: Fri, 12 Aug 2022 21:53:23 +0300 Message-Id: <83v8qxmgyk.fsf@gnu.org> From: Eli Zaretskii To: Matt Armstrong In-Reply-To: <874jyhgxak.fsf@rfc20.org> (message from Matt Armstrong on Fri, 12 Aug 2022 10:57:07 -0700) Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks References: <87ilmygjyv.fsf@rfc20.org> <87edxmgjke.fsf@rfc20.org> <83o7wqnfu8.fsf@gnu.org> <874jyhgxak.fsf@rfc20.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Matt Armstrong > Cc: 57150@debbugs.gnu.org > Date: Fri, 12 Aug 2022 10:57:07 -0700 > > Do you have a preference between the two general approaches to > exercising many similar test cases: data driven vs. macro driven? I tend to like the data-driven approach better, but I have nothing against macros, assuming they solve the issues that I described. > If data driven tests are preferred, what do you think of using 'message' > to log the individual test case details, as a way of knowing which part > failed? I have no problems with that, assuming that the text emitted by 'message' is visible when running the tests in batch mode. > Other test frameworks have scoped based context messages. In > pseudocode, something like: > > (ert-deftest example () > (dolist arg '(a b c d) > (context (arg) > (should (equal arg (identity-function arg)))))) > > Printed failures would include both the normal 'should' output, but also > the values passed to 'context'. > > I notice that ERT does have two interactive features that partially > address this. These commands are available in its UI: > > ‘l’ > Show the list of ‘should’ forms executed in the test > (‘ert-results-pop-to-should-forms-for-test-at-point’). > > ‘m’ > Show any messages that were generated (with the Lisp function > ‘message’) in a test or any of the code that it invoked > (‘ert-results-pop-to-messages-for-test-at-point’). > > In simpler tests I find that 'l' is enough, since I can count the > 'should' calls to work out the iteration of whatever loop is used by the > test. In more complex cases, perhaps using 'message' to display the > context is enough? > > If you don't think 'l' and 'm' are *not* good enough, I might agree with > you. I'm not sure I understand how these commands are relevant. I'm talking about running the tests in batch mode. How do I make use of those commands in that case? > If you think adding something like 'context' to ERT is worthwhile > I can look at doing that. > > For this patch, perhaps using 'message' is best? Anything is fine with me, if it shows enough information to identify the particular "should" test that failed in the code. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 00:07:00 2022 Received: (at 57150) by debbugs.gnu.org; 13 Aug 2022 04:07:00 +0000 Received: from localhost ([127.0.0.1]:59364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMiQO-0000Cm-0X for submit@debbugs.gnu.org; Sat, 13 Aug 2022 00:07:00 -0400 Received: from mail-pj1-f51.google.com ([209.85.216.51]:53862) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMiQJ-0000CX-Uy for 57150@debbugs.gnu.org; Sat, 13 Aug 2022 00:06:58 -0400 Received: by mail-pj1-f51.google.com with SMTP id pm17so2593848pjb.3 for <57150@debbugs.gnu.org>; Fri, 12 Aug 2022 21:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=ia4j0pjPS/yDHLDlTV9bCiB0ghrok+tcDoov+h+1H14=; b=ZpZrGom37YbSik69TI3gaJibV5E0p4a0Gfs/lTdUn0GU2dFZWz50lSl5XVTJfGtnE+ WQYBgLw/MXluJ66VKgzoanXZHirdre2LFgG03pvNHrvuDVCBTXNjZLDlswrGpFhaIJs8 WovCjzczEyWZ/Hz/Xn2FTf+7a1Y0E+MUotDl6qv3YzSGzu9a3WUp2FiGFPCPGyLJWFvy ibREh6slhuXIMw9V7SNjo6ffm+oFNr1qrd2jx89jy9e4rJndnp8vjQN+1jWTeWEKNHXr NWOzuMyyYXsSE2gIRR7mkJZ7UvZ1nTrYTXsmGnF4o+skUvYxRZEUH6WBJwpEEE8VYMtK T39g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=ia4j0pjPS/yDHLDlTV9bCiB0ghrok+tcDoov+h+1H14=; b=i8ciRdjUHTKZwuXL12v0Nbtjce9sOADLcZtToxgNdHWClYN6sHVN9KvMv5Zw3DtKb7 e2bvjkA9XDpwm3i3aoKUXURFfuIXy6gOwsOEe/SShmI8Ve0HaQGhPqoT0XnSJeyXSklc g/nIVHYj7BNQkn5Pm84r923cqtpLFva+29nUvQ0UuPpbYH/RH5YCEZtK/MSYFT88GXWn 1f/j+xp3wNt4tsZKQGNMcLv/TQIzElCf8/1F/+tZ8EZi1ixDlkAy9TqWeuB1IbxUCtoB DPVx0bPkTdqsHDlc35uKHU9qOmKKt58IDCLLweuoXCOqZUywmDWXRJQrGOsbuOYuChNQ psqg== X-Gm-Message-State: ACgBeo3C6UDGXMqUraBpxSeaa6EdXQxADwU7aQ3SSvgpilPgmpO7yJcl ojYSHFJ3z59nXe0bWhXSUKI= X-Google-Smtp-Source: AA6agR6sm5mkiXxKztH/Hil4m+aTPHMbDGl6bqhLHIiL6hIdR/NymZiFvLRKYBz3IGQu1hqC5n3HVA== X-Received: by 2002:a17:90a:8001:b0:1f4:fe95:c420 with SMTP id b1-20020a17090a800100b001f4fe95c420mr7571343pjn.146.1660363609710; Fri, 12 Aug 2022 21:06:49 -0700 (PDT) Received: from localhost ([2409:8a70:2bf:80b0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id b12-20020a621b0c000000b005255f5d8f9fsm2431725pfb.112.2022.08.12.21.06.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 21:06:49 -0700 (PDT) From: Ihor Radchenko To: Matt Armstrong Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <87ilmygjyv.fsf@rfc20.org> References: <87ilmygjyv.fsf@rfc20.org> Date: Sat, 13 Aug 2022 12:07:49 +0800 Message-ID: <878rns946i.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Matt Armstrong writes: > I noticed there was no explicit test against the overlay modification > hook boundary conditions. The attached patch adds some, which might be > nice to have if a person (possibly me) someday optimizes overlay > performance with a change in data structure. Just in case. Have you seen https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00323.html ? I am not sure how much progress have been made on the noverlay branch, but there was at least some existing test suitcase in there. Not sure if it has been merged or if your proposed patch is not covered. Best, Ihor From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 20:45:13 2022 Received: (at 57150) by debbugs.gnu.org; 14 Aug 2022 00:45:13 +0000 Received: from localhost ([127.0.0.1]:35385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN1kf-00035D-1n for submit@debbugs.gnu.org; Sat, 13 Aug 2022 20:45:13 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:35935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN1kb-00034v-Fk for 57150@debbugs.gnu.org; Sat, 13 Aug 2022 20:45:11 -0400 Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 5337F100002; Sun, 14 Aug 2022 00:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1660437902; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Hv1nVJaxTsShVojeUVjxQ72D+DdvEU/w/RxDtPdYqg=; b=f6s1VF2HoETlGaSSkrEFb4TocBGmDcrZcdjlPAHgzObO54WPSZlTX3dgGdEMZha1hFyyAN cQplEMfWELXIaToSNU1lDXWpxjdCsHL+k7tVcwY7DMlZ7xUzAmNxnkwGK4N0P98sdOmxcg 2r4qUnTZrLBo1gZjwjtdsn+UetLB2VXQzZdjRyB89aluIK/Wx8cbhXGpKMJBtBbHM6dQe7 YPXFzSIe4187fV7zKvEbWVRNno/vuLuM6ctOgTcCo06f8C1BWZJQGHgTxEkCQyGG7QJgdO WtZP+dS5t5IFZTcvGxBiANqyerMng4yM0s9z8nmVpuAsQlvbB6pTQf0e0MKl1w== Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1oN1kR-000Gbr-1Y; Sat, 13 Aug 2022 17:44:59 -0700 From: Matt Armstrong To: Ihor Radchenko Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <878rns946i.fsf@localhost> References: <87ilmygjyv.fsf@rfc20.org> <878rns946i.fsf@localhost> Date: Sat, 13 Aug 2022 17:44:59 -0700 Message-ID: <87zgg7fyb8.fsf@rfc20.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Ihor Radchenko writes: > Matt Armstrong writes: > >> I noticed there was no explicit test against the overlay modification >> hook boundary conditions. The attached patch adds some, which might be >> nice to have if a person (possibly me) someday optimizes overlay >> performance with a change in data structure. > > Just in case. Have you seen > https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00323.htlm > ? > > I am not sure how much progress have been made on the noverlay branch, > but there was at least some existing test suitcase in there. Not sure if > it has been merged or if your proposed patch is not covered. Yes, thank you for pointing that out. I have gone as far as importing the entire history of emacs-devel into https://notmuchmail.org/ and read as much history about the overlay problem as I could discover. I have been in contact with both Andreas (the original feature/noverlay author) and Vladimir (who later examined it). Andreas had no plans to return to looking at the problem and did not recall the precise state the branch was left in. Vladimir, despite his interest, was unfortunately not able to get his employer to sign FSF papers. Both wished me luck. Fortunately all of the test cases from the feature/noverlay branch were merged to the master branch, I believe by Eli, shortly after they were written years ago. As for feature/noverlay itself, I have been exploring alternative approaches that might be simpler or clearer than Andreas' approach, with the clear advantage of seeing his implementation, of course. Failing any improvement I can always start right where he left off. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 00:52:38 2022 Received: (at 57150) by debbugs.gnu.org; 14 Aug 2022 04:52:38 +0000 Received: from localhost ([127.0.0.1]:35593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN5c5-00057S-78 for submit@debbugs.gnu.org; Sun, 14 Aug 2022 00:52:37 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:59569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN5bz-00057A-U1 for 57150@debbugs.gnu.org; Sun, 14 Aug 2022 00:52:35 -0400 Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 7E7F7C0002; Sun, 14 Aug 2022 04:52:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1660452746; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9wzNpJ19NPd8BUS2wDb8tn26Pcli63qnf3P8zsJVz74=; b=YlythECY2qATCNUka8EcgeBEYsRMEluhwwt9CbF+EjPtXK2ZsL5Bvj0MqWxYfvX4UeFG+q uLwuDSfBEXhkbhdpUMt3LadVCoIviAsNU2i9NdIIyZ3AqLrXRT9Zo8ovd3C4qS78wlf1BM AsIkFxDrYYq1zhLpp1USPTGo39j9qDNANe98VU6nKLtbZPrQgSokdnDtGvxF82Hud48BsW USBvgXeSaCWpGGmQ47VG4h1Bi9txZwVhLok/fuiX2qsEDM8SRYoPZDT1mbikpcJ1V7QzcO kW1wrPVf8+WxrnVkLdXJdrweGYQUB8DY4WPBh6oFNCNfOTH7ZeQpX8hLbDR6RA== Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1oN5bq-000JA0-1m; Sat, 13 Aug 2022 21:52:22 -0700 From: Matt Armstrong To: Eli Zaretskii Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <83o7wqnfu8.fsf@gnu.org> References: <87ilmygjyv.fsf@rfc20.org> <87edxmgjke.fsf@rfc20.org> <83o7wqnfu8.fsf@gnu.org> Date: Sat, 13 Aug 2022 21:52:22 -0700 Message-ID: <87k07bctq1.fsf@rfc20.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Thanks Eli, another patch attached. More comments below. Eli Zaretskii writes: >> From: Matt Armstrong >> Date: Thu, 11 Aug 2022 21:41:21 -0700 >> >> Matt Armstrong writes: >> >> > I noticed there was no explicit test against the overlay modification >> > hook boundary conditions. The attached patch adds some, which might >> > be nice to have if a person (possibly me) someday optimizes overlay >> > performance with a change in data structure. >> > >> > In writing this I was surprised to learn that the hooks do not behave >> > differently if the overlay is `front-advance' or `rear-advance', so >> > this is explicitly tested. >> >> ...follow up with a comment typo fix. > > Thanks! Adding tests is always welcome, so this is fine, of course. > Please allow me a few minor comments, though. > > A frequent gripe of mine about our test-suite tests is that the ideas > of the tests are not sufficiently explained, where they aren't 110% > obvious. The ERT framework and the tests themselves being highly > macro-ized don't help in that matter, either. So please try to > explain the idea of the tests and the details of the data structures > as much as is reasonably possible. In this case: I switched to an approach where each test case is specified by an alist with keys bound to variables with `let-alist'. This lets me log the test case "spec" with `message' while still conveniently unpacking the alist. I also switched to an approach where the "recorded" modification hook calls are stored on a property on the overlay itself, which then made it easy to extract this somewhat tricky code into helper functions. I added some message output, including a message printing the "test spec" alist before it executes. I verified that this new message output is part of the test log (as captured by "make check") and appears on the console for failed tests. I also left a few other "debug log" style messages in the test case that I found helpful during debugging. I don't feel strongly about leaving them in or not. I left a TODO, which is more of a question, about one test case that reveals a call to the modification hooks for a simple insert, which the elisp manual seems to suggest will not happen (because inserts do not modify characters)...perhaps the manual is worded too strongly? Am I misunderstanding something? Ironically, after all this was done, I am left wondering if a well designed macro fixture wouldn't be more clear, simply because it does produce a separate ERT test for each test case. Perhaps there are ways to design macro test fixtures in clear ways to avoid the downsides of the way they appear in the other buffer-tests.el tests today.... > This means you don't test so-called "empty" overlays, whose START and > END are identical. They are handled specially by the low-level > support code. Maybe add more tests for that? I added one test case for an empty overlay. I'm not confident I've covered all of the interesting cases, but nothing obvious occurred to me. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Add-basic-test-coverage-for-overlay-modification-hoo.patch >From 3a3fbf96ce64e8a40a849c3b3f8453614a92b728 Mon Sep 17 00:00:00 2001 From: Matt Armstrong Date: Thu, 11 Aug 2022 21:11:36 -0700 Subject: [PATCH] Add basic test coverage for overlay modification hooks * test/src/buffer-tests.el: (overlay-modification-hooks) new ert-deftest. (overlay-tests-start-recording-modification-hooks): New function. (overlay-tests-get-recorded-modification-hooks): New function. --- test/src/buffer-tests.el | 193 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 193 insertions(+) diff --git a/test/src/buffer-tests.el b/test/src/buffer-tests.el index 3c6a9208ff..558d05de14 100644 --- a/test/src/buffer-tests.el +++ b/test/src/buffer-tests.el @@ -22,6 +22,199 @@ (require 'ert) (require 'ert-x) (require 'cl-lib) +(require 'let-alist) + +(defun overlay-tests-start-recording-modification-hooks (overlay) + "Start recording modification hooks on OVERLAY. + +Always overwrites the `insert-in-front-hooks', +`modification-hooks' and `insert-behind-hooks' properties. Any +recorded history from a previous call is erased. + +The history is stored in a property on the overlay itself. Call +`overlay-tests-get-recorded-modification-hooks' to retrieve the +recorded calls conveniently." + (dolist (hooks-property '(insert-in-front-hooks + modification-hooks + insert-behind-hooks)) + (overlay-put + overlay + hooks-property + (list (lambda (ov &rest args) + (message " %S called on %S with args %S" hooks-property ov args) + (should inhibit-modification-hooks) + (should (eq ov overlay)) + (push (list hooks-property args) + (overlay-get overlay + 'recorded-modification-hook-calls))))) + (overlay-put overlay 'recorded-modification-hook-calls nil))) + +(defun overlay-tests-get-recorded-modification-hooks (overlay) + "Extract the recorded calls made to modification hooks on OVERLAY. + +Must be preceded by a call to +`overlay-tests-start-recording-modification-hooks' on OVERLAY. + +Returns a list. Each element of the list represents a recorded +call to a particular modification hook. + +Each call is itself a sub-list where the first element is a +symbol matching the modification hook property (one of +`insert-in-front-hooks', `modification-hooks' or +`insert-behind-hooks') and the second element is the list of +arguments passed to the hook. The first hook argument, the +overlay itself, is omitted to make test result verification +easier." + (reverse (overlay-get overlay + 'recorded-modification-hook-calls))) + +(ert-deftest overlay-modification-hooks () + "Test the basic functionality of overlay modification hooks. + +This exercises hooks registered on the `insert-in-front-hooks', +`modification-hooks' and `insert-behind-hooks' overlay +properties." + ;; This is a data driven test loop. Each test case is described + ;; by an alist. The test loop initializes a new temporary buffer + ;; for each case, creates an overlay, registers modification hooks + ;; on the overlay, modifies the buffer, and then verifies which + ;; modification hooks (if any) were called for the overlay, as + ;; well as which arguments were passed to the hooks. + ;; + ;; The following keys are available in the alist: + ;; + ;; `buffer-text': the initial buffer text of the temporary buffer. + ;; Defaults to "1234". + ;; + ;; `overlay-beg' and `overlay-end': the begin and end positions of + ;; the overlay under test. Defaults to 2 and 4 respectively. + ;; + ;; `insert-at': move to the given position and insert the string + ;; "x" into the test case's buffer. + ;; + ;; `replace': replace the first occurrence of the given string in + ;; the test case's buffer with "x". The test will fail if the + ;; string is not found. + ;; + ;; `expected-calls': a description of the expected buffer + ;; modification hooks. See + ;; `overlay-tests-get-recorded-modification-hooks' for the format. + ;; May be omitted, in which case the test will insist that no + ;; modification hooks are called. + ;; + ;; The test will fail itself in the degenerate case where no + ;; buffer modifications are requested. + (dolist (test-case + '( + ;; Remember that the default buffer text is "1234" and + ;; the default overlay begins at position 2 and ends at + ;; position 4. Most of the test cases below assume + ;; this. + + ;; TODO: (info "(elisp) Special Properties") says this + ;; about `modification-hooks': "Furthermore, insertion + ;; will not modify any existing character, so this hook + ;; will only be run when removing some characters, + ;; replacing them with others, or changing their + ;; text-properties." So, why are modification-hooks + ;; being called when inserting at position 3 below? + ((insert-at . 1)) + ((insert-at . 2) + (expected-calls . ((insert-in-front-hooks (nil 2 2)) + (insert-in-front-hooks (t 2 3 0))))) + ((insert-at . 3) + (expected-calls . ((modification-hooks (nil 3 3)) + (modification-hooks (t 3 4 0))))) + ((insert-at . 4) + (expected-calls . ((insert-behind-hooks (nil 4 4)) + (insert-behind-hooks (t 4 5 0))))) + ((insert-at . 5)) + + ;; Replacing text never calls `insert-in-front-hooks' + ;; or `insert-behind-hooks'. It calls + ;; `modification-hooks' if the overlay covers any text + ;; that has changed. + ((replace . "1")) + ((replace . "2") + (expected-calls . ((modification-hooks (nil 2 3)) + (modification-hooks (t 2 3 1))))) + ((replace . "3") + (expected-calls . ((modification-hooks (nil 3 4)) + (modification-hooks (t 3 4 1))))) + ((replace . "4")) + ((replace . "12") + (expected-calls . ((modification-hooks (nil 1 3)) + (modification-hooks (t 1 2 2))))) + ((replace . "23") + (expected-calls . ((modification-hooks (nil 2 4)) + (modification-hooks (t 2 3 2))))) + ((replace . "34") + (expected-calls . ((modification-hooks (nil 3 5)) + (modification-hooks (t 3 4 2))))) + ((replace . "123") + (expected-calls . ((modification-hooks (nil 1 4)) + (modification-hooks (t 1 2 3))))) + ((replace . "234") + (expected-calls . ((modification-hooks (nil 2 5)) + (modification-hooks (t 2 3 3))))) + ((replace . "1234") + (expected-calls . ((modification-hooks (nil 1 5)) + (modification-hooks (t 1 2 4))))) + + ;; Inserting at the position of a zero-length overlay + ;; calls both `insert-in-front-hooks' and + ;; `insert-behind-hooks'. + ((buffer-text . "") (overlay-beg . 1) (overlay-end . 1) + (insert-at . 1) + (expected-calls . ((insert-in-front-hooks + (nil 1 1)) + (insert-behind-hooks + (nil 1 1)) + (insert-in-front-hooks + (t 1 2 0)) + (insert-behind-hooks + (t 1 2 0))))))) + (message "BEGIN overlay-modification-hooks test-case %S" test-case) + + ;; All three hooks ignore the overlay's `front-advance' and + ;; `rear-advance' option, so test both ways while expecting the same + ;; result. + (dolist (advance '(nil t)) + (message " advance is %S" advance) + (let-alist test-case + (with-temp-buffer + ;; Set up the temporary buffer and overlay as specified by + ;; the test case. + (insert (or .buffer-text "1234")) + (let ((overlay (make-overlay + (or .overlay-beg 2) + (or .overlay-end 4) + nil + advance advance))) + (message " (buffer-string) is %S" (buffer-string)) + (message " overlay is %S" overlay) + (overlay-tests-start-recording-modification-hooks overlay) + + ;; Modify the buffer, possibly inducing calls to the + ;; overlay's modification hooks. + (should (or .insert-at .replace)) + (when .insert-at + (goto-char .insert-at) + (insert "x") + (message " inserted \"x\" at %S, buffer-string now %S" + .insert-at (buffer-string))) + (when .replace + (goto-char (point-min)) + (search-forward .replace) + (replace-match "x") + (message " replaced %S with \"x\"" .replace)) + + ;; Verify that the expected and actual modification hook + ;; calls match. + (should (equal + .expected-calls + (overlay-tests-get-recorded-modification-hooks + overlay))))))))) (ert-deftest overlay-modification-hooks-message-other-buf () "Test for bug#21824. -- 2.35.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 14 03:15:32 2022 Received: (at 57150) by debbugs.gnu.org; 14 Aug 2022 07:15:33 +0000 Received: from localhost ([127.0.0.1]:35706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN7qO-0000ha-Ie for submit@debbugs.gnu.org; Sun, 14 Aug 2022 03:15:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN7qM-0000hO-Tu for 57150@debbugs.gnu.org; Sun, 14 Aug 2022 03:15:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40930) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oN7qH-000820-Go; Sun, 14 Aug 2022 03:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QbwuR95LbH88eIQgNBdWL9MPWo287Kl0qoRgwnkojfU=; b=fPdoLQtW/Yy9 EnvdKl4ULSEpDjy5mBw/DpzuKeOxUClv7AwYYW7vE21Tdx+GphSLEyPMN7HsUM42n9x+H+65UXphC itiYbyM/IdzmXR9LCC71nSfkBPIgfH6suC40gTPNWuMVLSG8zRHf4ZLbhQOgp6xugLGECcKweoDKz r/5sGp6GOg8oeh3x2kftIbhai7D40t6JS3Xm+CwmZmWGK6nlmsJGGFqfeQoapi+gXAeWQSji+7p5A iW1vHR2YRSXkjReXOcVQndSv2rTLGeQ/BKSHsbNR4CG+Us/H363DfwhWTkBphsqnk7woM92yIthMy nkLCK4LwjWva4ojUdlrgDw==; Received: from [87.69.77.57] (port=2265 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 1oN7qG-0004Bt-OZ; Sun, 14 Aug 2022 03:15:25 -0400 Date: Sun, 14 Aug 2022 10:15:08 +0300 Message-Id: <83a687l2ir.fsf@gnu.org> From: Eli Zaretskii To: Matt Armstrong In-Reply-To: <87k07bctq1.fsf@rfc20.org> (message from Matt Armstrong on Sat, 13 Aug 2022 21:52:22 -0700) Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks References: <87ilmygjyv.fsf@rfc20.org> <87edxmgjke.fsf@rfc20.org> <83o7wqnfu8.fsf@gnu.org> <87k07bctq1.fsf@rfc20.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Matt Armstrong > Cc: 57150@debbugs.gnu.org > Date: Sat, 13 Aug 2022 21:52:22 -0700 > > Thanks Eli, another patch attached. More comments below. This is very good, thanks! > Ironically, after all this was done, I am left wondering if a well > designed macro fixture wouldn't be more clear, simply because it does > produce a separate ERT test for each test case. Perhaps there are ways > to design macro test fixtures in clear ways to avoid the downsides of > the way they appear in the other buffer-tests.el tests today.... It is okay to make several tests in a single ert-deftest test, as long as each failing test is clearly explained and easily correlated to the source code that failed. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 15 00:13:45 2022 Received: (at 57150) by debbugs.gnu.org; 15 Aug 2022 04:13:45 +0000 Received: from localhost ([127.0.0.1]:40272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNRU0-0000TT-Ju for submit@debbugs.gnu.org; Mon, 15 Aug 2022 00:13:44 -0400 Received: from mail-pj1-f41.google.com ([209.85.216.41]:51754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNRTx-0000TE-5J for 57150@debbugs.gnu.org; Mon, 15 Aug 2022 00:13:42 -0400 Received: by mail-pj1-f41.google.com with SMTP id t22so6014724pjy.1 for <57150@debbugs.gnu.org>; Sun, 14 Aug 2022 21:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=4EbahudfHkoHKws4fhzWFjybQmaFIdXmzudbY4dHW6s=; b=hIhLIGOiuSYWkf0lPG3SLMZzQfGXTQl+RmLOqgxdmUl2uoHZW+UqmKoxB34z9LtdCR GZu3yIGxPlpPT6YC/pfZpDp073Reb4fYB9QXldp0jaIhAlzf35g8KXT6g4MKcDnd2xS8 p+cNO0hFzo7o8udpXHI9b/ZIPuT8JKJ8LHfE1JEa2Juh471sTqpqlbOz3Mx3Fbwe9OOA kW1YMQB0Ah7iXwVMpuiM+NEb89kQsMa6gtelGiLTYAxe1SLhSo9aj/EnWsXaUfF/ZPw2 rMb427TgbvWTUjCyz8EUtDF4H54wEMufbGxNufx+LUapHkLmA30Qe9r3p/sXD9ptkgGn geXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=4EbahudfHkoHKws4fhzWFjybQmaFIdXmzudbY4dHW6s=; b=ecJZo7KX7rHbsh+cBoK0JwmD4Jo2fzBpKlNRqbX7cDp7QLZm4nxED+tNEcYfnWzj57 nmRFgxC9nJd/OCEIub2PS6KnLsKW5DRAJ3azUfRjv2FHpdwXoG7Q87me51/lzk2+Dn27 lpcQmXAN/NPAogiaTvsbtDdVlZe449txKdwdlhbfJZeYkeXuxtCxBi2ros701SRGnq1B mBSwx6KWENxekI7BCw8xUGspgwn6F4azB6OEMmiDQ4LQbhrm/PA1wImcsFos4PD4C4oP kTm9Gu7kfkdWF77mgJ0w9g4+Zc9dcKX7MWgBAS/wh65CI7Y2YJmu//SstigABQGmZI8T NwrQ== X-Gm-Message-State: ACgBeo00WrYksibKqHKex+oOjVIXk4N2XySyYvQSNTPqViR8TypFLcmd WcTfguEydvIyWLiv8fA5szQ= X-Google-Smtp-Source: AA6agR5xiiT/GhNh9Cf52nUA8JNitcJ1LBvNsaCG+BYyueIbC76wJhq3wAuVtgl3peQ0tYvzMJavMA== X-Received: by 2002:a17:902:bb95:b0:16e:e3f4:8195 with SMTP id m21-20020a170902bb9500b0016ee3f48195mr15222516pls.130.1660536815188; Sun, 14 Aug 2022 21:13:35 -0700 (PDT) Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id d6-20020a170903230600b0016cb873fe6fsm6156799plh.183.2022.08.14.21.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Aug 2022 21:13:34 -0700 (PDT) From: Ihor Radchenko To: Matt Armstrong Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <87zgg7fyb8.fsf@rfc20.org> References: <87ilmygjyv.fsf@rfc20.org> <878rns946i.fsf@localhost> <87zgg7fyb8.fsf@rfc20.org> Date: Mon, 15 Aug 2022 12:14:37 +0800 Message-ID: <87y1vqxhw2.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 57150 Cc: 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Matt Armstrong writes: > As for feature/noverlay itself, I have been exploring alternative > approaches that might be simpler or clearer than Andreas' approach, with > the clear advantage of seeing his implementation, of course. Failing > any improvement I can always start right where he left off. This will be most welcome. At least, Org mode can greatly benefit from faster overlays. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 15 07:26:45 2022 Received: (at 57150) by debbugs.gnu.org; 15 Aug 2022 11:26:45 +0000 Received: from localhost ([127.0.0.1]:41011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNYF2-0004D5-Nc for submit@debbugs.gnu.org; Mon, 15 Aug 2022 07:26:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNYF1-0004Ct-Gp for 57150@debbugs.gnu.org; Mon, 15 Aug 2022 07:26:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36634) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNYEw-0006AU-5R; Mon, 15 Aug 2022 07:26:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TcUR42E8iMNMV0kA015Ghss9EcU+o+d0TTRMIrBD49c=; b=paeVmobtKFD2 ogViviNZZCmnOi8/7HtrPbdH4KNrcXfJ7UZOc++jrONkmKYxIwFTas3MA58RVMhQHsGjvxSbtFHOA 6YpwtOYqEaWwhZdhQqGitQEt4CWuK6sJQvwoHDJ9YHpF4mrPn7gw489ghO+MV2Jqi86O7z/jfGGOc /dfwlXdJ0Gsnu0qMJzFsQjXbDOe6yPLMRoHjkdEd4lwVaf8gR4zjpYLz0532jLKma/wpZnQxg0x4X YTx/lHQ36EV8sUsDxIchSxvJbcV82B7SMYyT1VABszZsWRaG0fSJqPuVmrO5G3Mzhaql1RY2LO9Q5 GUbb8Io4CJuFX8sQZsqFxQ==; Received: from [87.69.77.57] (port=2764 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 1oNYEv-0002ff-LR; Mon, 15 Aug 2022 07:26:37 -0400 Date: Mon, 15 Aug 2022 14:26:23 +0300 Message-Id: <83mtc5iw80.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87y1vqxhw2.fsf@localhost> (message from Ihor Radchenko on Mon, 15 Aug 2022 12:14:37 +0800) Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks References: <87ilmygjyv.fsf@rfc20.org> <878rns946i.fsf@localhost> <87zgg7fyb8.fsf@rfc20.org> <87y1vqxhw2.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: matt@rfc20.org, 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 57150@debbugs.gnu.org > From: Ihor Radchenko > Date: Mon, 15 Aug 2022 12:14:37 +0800 > > At least, Org mode can greatly benefit from faster overlays. The problems with overlays in Emacs are much wider than just Org. Our performance sucks in many cases because of that. Just two examples that were mentioned lately in the "long-line optimizations" discussion: show-paren-mode and isearch-lazy-highlight -- each one of these two is capable of literally bringing Emacs to its knees, response-time wise. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 16 22:50:47 2022 Received: (at 57150) by debbugs.gnu.org; 17 Aug 2022 02:50:47 +0000 Received: from localhost ([127.0.0.1]:48878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oO98o-0001ig-Tk for submit@debbugs.gnu.org; Tue, 16 Aug 2022 22:50:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oO98l-0001iN-Mv for 57150@debbugs.gnu.org; Tue, 16 Aug 2022 22:50:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34640) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO98g-0002iV-Cg; Tue, 16 Aug 2022 22:50:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=2wIhlqsOBxoP3SUFQ8mK3e97k2ROZDbrkjGjNn/P+VY=; b=bbVQBfBWigJQ OzCzFfx+Nq9NAsM06iI5ZumnZr2ErAKzvj26wvRqzNOZm13OOpbxIeH6gUnf+Z3wGdf+qOt4V3LXJ ZDjqpk40HDrMYcFkc1fOOYsZ592ZdqyLJHZ6r6aZkacv0BoPWjn+RU3Vig8mrhxOanUzH5zcuarKk Enl2tljMK1FVlvDjz5SUwcZ9mYDYt5yIKEF+bk4Crw0MMfp75kD1p9S/76X2tRqLZ2+9Q+mqQRHPh 4wedocvfqmKmdU45LLPrPCNx8csre2W29JGyNZzK3++1PTYem5rKnVXqsBUTy5wpo2E8KboWUHHme +1NadMdz/e7jOMj+wA2V+Q==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1oO98g-0008JS-3o; Tue, 16 Aug 2022 22:50:38 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83mtc5iw80.fsf@gnu.org> (message from Eli Zaretskii on Mon, 15 Aug 2022 14:26:23 +0300) Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks References: <87ilmygjyv.fsf@rfc20.org> <878rns946i.fsf@localhost> <87zgg7fyb8.fsf@rfc20.org> <87y1vqxhw2.fsf@localhost> <83mtc5iw80.fsf@gnu.org> Message-Id: Date: Tue, 16 Aug 2022 22:50:38 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: matt@rfc20.org, yantar92@gmail.com, 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The problems with overlays in Emacs are much wider than just Org. Our > performance sucks in many cases because of that. Just two examples > that were mentioned lately in the "long-line optimizations" > discussion: show-paren-mode and isearch-lazy-highlight -- each one of > these two is capable of literally bringing Emacs to its knees, > response-time wise. The first question is, should these use text properties instead of overlays? Are they using many overlays to highlight many potential matches in a long buffer? If so, would it make sense to show, at any time, only those that are near point? When you move to a far-away part of the buffer, it could add highlighting to the matches near there. But maybe it can avoid ever trying to highlight more than a few parts of the buffer. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 17 06:04:07 2022 Received: (at 57150) by debbugs.gnu.org; 17 Aug 2022 10:04:07 +0000 Received: from localhost ([127.0.0.1]:49458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOFuB-0006in-1V for submit@debbugs.gnu.org; Wed, 17 Aug 2022 06:04:07 -0400 Received: from mail-ot1-f46.google.com ([209.85.210.46]:44006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOFu8-0006iI-Bf for 57150@debbugs.gnu.org; Wed, 17 Aug 2022 06:04:06 -0400 Received: by mail-ot1-f46.google.com with SMTP id 53-20020a9d0838000000b006371d896343so9107840oty.10 for <57150@debbugs.gnu.org>; Wed, 17 Aug 2022 03:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=W8a3offPk9V+/RUPx8vgTVE+aNwlGxB+hUnhqIUmWmA=; b=dOy4RmD+M2mE1ULZfXGY8P7F3V5xW9A3UwR6nfQNRdjX/OR7JwoH7LJjYiZzIysJmO MH+L42dSMe22Umbldksu+U0vVwr9796yJ9QF8rulIyoOJO34AMNblAJxqq+n8r0GbYxR sMlRXYQ+F6Np6n5LNpqEKbyLmTvyVk3Nd4Lgo+1QcPUk7r+KqrJQstSyd3c9jjXmqqAp /IBKe37BCDk406QYa0kExV6K7yOiJmqMy/twKPzKzWUCDn7x+9CvIH3HU1kFIOQIPNF1 WHQT8cL2dDXRvlgpH3skJwhJ51+iBpAhIxvxV0QIbjxKO5X83kzL4MKVybJdv6POtybc QaEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=W8a3offPk9V+/RUPx8vgTVE+aNwlGxB+hUnhqIUmWmA=; b=QJomu3bWvr2+NuQpgOao7waBlUO8cvBXEa/pi9I9TTdcxiHY/RUrDUr7AD1mO+s776 iUOgui3gtP9kecE247scpp1hYXGh0mHtJEmSnG1clSeEurOf8S4QkyP/NoYtN+WhGMbW CDl5M4RJCBKMjsU1ZS7TiCCr7gxwacvzkTsHCcBVmJpRhTeHGMVwypzw7bkqct8kUmT6 ioKRUT3q3MQpT7AhoXb8Ja+ABirZuNH2dn6hl6bz2mL8Vr+LU0p7isVYyrBBeruphhCW g1tcAdeuBHcICOlSfDEkyfe4C85+jPvLhbDX8U47FHvxTHDtVNJyl/a0f1N5hR+qQTf4 AjEA== X-Gm-Message-State: ACgBeo07cYJeVjdRLFwcntFTwk8vx4L2aWdnvMUpz4kR9HH2k9hbpf+3 4sBU45WFkI/5hCSK9hs62Vc= X-Google-Smtp-Source: AA6agR4bZ3yxK/TMNCKTFA7rR5UreYEGKav/IuAzA1Gulon98bE5UrTh8lCn9QwtxV3CinMKqQiddg== X-Received: by 2002:a05:6830:18fa:b0:638:d46c:1374 with SMTP id d26-20020a05683018fa00b00638d46c1374mr2043749otf.142.1660730638619; Wed, 17 Aug 2022 03:03:58 -0700 (PDT) Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id t2-20020a4a8242000000b004357ccfc8bfsm2912379oog.7.2022.08.17.03.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 03:03:57 -0700 (PDT) From: Ihor Radchenko To: rms@gnu.org Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: References: <87ilmygjyv.fsf@rfc20.org> <878rns946i.fsf@localhost> <87zgg7fyb8.fsf@rfc20.org> <87y1vqxhw2.fsf@localhost> <83mtc5iw80.fsf@gnu.org> Date: Wed, 17 Aug 2022 18:05:00 +0800 Message-ID: <87zgg3yylv.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 57150 Cc: matt@rfc20.org, Eli Zaretskii , 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Richard Stallman writes: > The first question is, should these use text properties instead of > overlays? It may be possible, but there are non-trivial implications when one attempts to replace overlays with text properties. Some implications I can remember quickly: (1) Overlays do not overwrite original properties and thus removing overlays automatically recovers the original properties. Not so easily when using text properties. (2) Overlays are not copied when the text is killed. Text properties are. Overlays are also not carried between indirect buffers. (3) Inserting text inside overlays automatically inherits their properties. To do the same with text properties, one must use special functions like `insert-and-inherit', which is not common in packages. To conclude, overlays and text-properties are similar in many aspects, but also handled differently in other aspects. These differences make it very annoying to change from overlays to text property approaches. > Are they using many overlays to highlight many potential matches in a > long buffer? If so, would it make sense to show, at any time, only those > that are near point? When you move to a far-away part of the buffer, > it could add highlighting to the matches near there. But maybe it > can avoid ever trying to highlight more than a few parts of the buffer. I guess it can be a valid optimization in some cases. But it is not always possible. For example, consider folded headlines in Org mode. They have some initial folding state set when opening the file, but the state can be changed any time by the user. It is technically challenging to put overlays on the fly in such scenario. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 17 07:51:48 2022 Received: (at 57150) by debbugs.gnu.org; 17 Aug 2022 11:51:48 +0000 Received: from localhost ([127.0.0.1]:49667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOHaO-0007lH-5v for submit@debbugs.gnu.org; Wed, 17 Aug 2022 07:51:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOHaK-0007ky-En for 57150@debbugs.gnu.org; Wed, 17 Aug 2022 07:51:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46048) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOHaE-0002Jm-Nq; Wed, 17 Aug 2022 07:51:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=EiAGd3YmcDEdTwUa3Eo1Xc2qfR311h70q6xICjMws0o=; b=q5q9sTIDMkJZ lvKuqOrcTxmg3/isPjQBZ31GJ/50JzETMcbgV+oJRMA8tzB37biB6fzwygTAEfhNfuqacuQAAd6Ko PAsP3wGifzJVT5DSBoLHWyKgTttClNvpJFaMRLXue4Rgla7IgT45qMhHmK6yVo5aYAAsmaxIGjiRg emY1aPQqTtwG5kB8EpOqRd3VNu8hzcl8viQyFZk4ImEZJJYPa8EN7JOP1wCUTxDIBAHUnjZ/leE+w SYkFKftLV2CiLF6uFvXLSc92573U0SfoTq+2rwagyvEW25zGs/MiMOEzVSB4OmHW4A1MJuLbeoB5u iE7fx/syrKdHvmEZurD6VQ==; Received: from [87.69.77.57] (port=4999 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 1oOHaB-0005mp-Nl; Wed, 17 Aug 2022 07:51:36 -0400 Date: Wed, 17 Aug 2022 14:51:26 +0300 Message-Id: <837d37dr5t.fsf@gnu.org> From: Eli Zaretskii To: rms@gnu.org In-Reply-To: (message from Richard Stallman on Tue, 16 Aug 2022 22:50:38 -0400) Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks References: <87ilmygjyv.fsf@rfc20.org> <878rns946i.fsf@localhost> <87zgg7fyb8.fsf@rfc20.org> <87y1vqxhw2.fsf@localhost> <83mtc5iw80.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: matt@rfc20.org, yantar92@gmail.com, 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Cc: yantar92@gmail.com, matt@rfc20.org, 57150@debbugs.gnu.org > Date: Tue, 16 Aug 2022 22:50:38 -0400 > > > The problems with overlays in Emacs are much wider than just Org. Our > > performance sucks in many cases because of that. Just two examples > > that were mentioned lately in the "long-line optimizations" > > discussion: show-paren-mode and isearch-lazy-highlight -- each one of > > these two is capable of literally bringing Emacs to its knees, > > response-time wise. > > The first question is, should these use text properties instead of > overlays? Text properties are less convenient when used for ephemeral highlighting. > Are they using many overlays to highlight many potential matches in a > long buffer? isearch-lazy-highlight does. > If so, would it make sense to show, at any time, only those > that are near point? When you move to a far-away part of the buffer, > it could add highlighting to the matches near there. But maybe it > can avoid ever trying to highlight more than a few parts of the buffer. isearch.el already attempts to do that, but its method of detecting what's out of the window doesn't work under truncate-lines. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 04 17:59:30 2022 Received: (at 57150) by debbugs.gnu.org; 4 Sep 2022 21:59:30 +0000 Received: from localhost ([127.0.0.1]:45870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oUxeM-0005xa-09 for submit@debbugs.gnu.org; Sun, 04 Sep 2022 17:59:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oUxeK-0005xL-69 for 57150@debbugs.gnu.org; Sun, 04 Sep 2022 17:59:28 -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:Date:References: In-Reply-To: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=Spj6+avFrdc4TmagQIVI5xkN8vVxFMbro8M8SvpcTno=; b=VXPn/B9kFSeXX+qy0DXLzYIRto 6VAyinb3hnllX9h6hFQtV6Qc8vsjpd1IGtT679v4KP1ZrY61YnO+swHva8cm/jCjPGy7oSdU6IolU aIO6f2Fe8zIue9quiZ91bIeH+2KVMbyUfRfsR7jS5Zyy2nOUMSUJ64Xlvv5lL/+B9rsY=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oUxeB-00036B-CQ; Sun, 04 Sep 2022 23:59:21 +0200 From: Lars Ingebrigtsen To: Matt Armstrong Subject: Re: bug#57150: 29.0.50; [PATCH] Add test coverage for overlay modification hooks In-Reply-To: <87k07bctq1.fsf@rfc20.org> (Matt Armstrong's message of "Sat, 13 Aug 2022 21:52:22 -0700") References: <87ilmygjyv.fsf@rfc20.org> <87edxmgjke.fsf@rfc20.org> <83o7wqnfu8.fsf@gnu.org> <87k07bctq1.fsf@rfc20.org> X-Now-Playing: Neil Young's _Harvest_: "Are You Ready For The Country?" Date: Sun, 04 Sep 2022 23:59:18 +0200 Message-ID: <87leqy6bt5.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Matt Armstrong writes: > From: Matt Armstrong > Date: Thu, 11 Aug 2022 21:11:36 -0700 > Subject: [PATCH] Add basic test coverage for overlay modification hooks Thanks; pushed to Emacs 29. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57150 Cc: Eli Zaretskii , 57150@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Matt Armstrong writes: > From: Matt Armstrong > Date: Thu, 11 Aug 2022 21:11:36 -0700 > Subject: [PATCH] Add basic test coverage for overlay modification hooks Thanks; pushed to Emacs 29. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 04 17:59:36 2022 Received: (at control) by debbugs.gnu.org; 4 Sep 2022 21:59:36 +0000 Received: from localhost ([127.0.0.1]:45873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oUxeS-0005xt-9S for submit@debbugs.gnu.org; Sun, 04 Sep 2022 17:59:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oUxeQ-0005xZ-Qp for control@debbugs.gnu.org; Sun, 04 Sep 2022 17:59:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ErgMTrYXj+xtnNwDfgeYivjkmlJ6lnpD6mT6xwef5/M=; b=femaUwJSJu2rdRkGc34FAxA18r kRTQWMO9+5pyVKsWbUd4fyAwOl2CVewCvD3OaQK4ahnK7sJgrX1mmfYtpTFBPb/MNaRunE5eeuopf qfv9TO1TOUd1C+2FPaKxLOQ0sqlkIh2ZgUdHpWHsd80G0wYTwvBMkRun0KYegCzXvG68=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oUxeJ-00036K-Ae for control@debbugs.gnu.org; Sun, 04 Sep 2022 23:59:29 +0200 Date: Sun, 04 Sep 2022 23:59:25 +0200 Message-Id: <87k06i6bsy.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #57150 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 57150 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 57150 29.1 quit From unknown Sun Aug 17 01:43:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 03 Oct 2022 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator