From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: "Phillip Lord" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Dec 2016 20:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 25111@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14808848632112 (code B ref -1); Sun, 04 Dec 2016 20:55:01 +0000 Received: (at submit) by debbugs.gnu.org; 4 Dec 2016 20:54:23 +0000 Received: from localhost ([127.0.0.1]:56192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDdnj-0000Y0-4G for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:23 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41377) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDdnh-0000Xn-JB for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDdnb-0007vR-Ku for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:16 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:53216) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cDdnb-0007vN-HX for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:15 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDdna-0002K5-DB for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 15:54:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDdnV-0007um-JX for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 15:54:14 -0500 Received: from mailgw.mycpanelcloud.co.uk ([185.116.214.213]:28432) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cDdnV-0007rm-8w for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 15:54:09 -0500 Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id B74AAC46B6 for ; Sun, 4 Dec 2016 21:53:09 +0000 (GMT) X-Virus-Scanned: by SpamTitan at mycpanelcloud.co.uk Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id DFDBFC445E for ; Sun, 4 Dec 2016 21:53:08 +0000 (GMT) Received: from cloud103.planethippo.com (cloud103.planethippo.com [31.216.48.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTPS id D6596C4417 for ; Sun, 4 Dec 2016 21:53:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:To:From:Subject:Date:Message-ID:Sender:Reply-To:Cc: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=qF/y+idlm+cA64TRgxGyU2RRuSl/3Q+xNMmbxJJ7kXA=; b=ZsXxa5W9AG6d0m+Svj2EMnRzY3 G0hYkWb+qncT9kGHwm/ZsOxrC3CFS5E3VUMwT2i622mRuARK6lLsBe2/UGOJwXfeTYUG1n8zxY0QQ E4+88JZ2G3lcEzkSdqhT8PYuknXHS21B1i+6wVRlXFIxO6ahafdRszi6exVs+MyKfjwYguTSKYfG8 nkGIEODIPcPiOisBkI80QFyXg1QIzE8iQGIv2BI0Cc53xQjLjZC2vkV6KO0mYN8eIGUiht9JZyqWt aLaANqe2NWD1KXsGQXvolsZ3uWwK9Ro+yzN8l2Z2hbjAvXen8V7rYxYUzUoMoB3+XMKlrDFsYgcqr ku/5bBZg==; Received: from [127.0.0.1] (port=49121 helo=cloud103.planethippo.com) by cloud103.planethippo.com with esmtpa (Exim 4.87) (envelope-from ) id 1cDdmm-0022HK-PH for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 20:53:24 +0000 Received: from 77.103.60.43 ([77.103.60.43]) (SquirrelMail authenticated user phillip.lord@russet.org.uk) by cloud103.planethippo.com with HTTP; Sun, 4 Dec 2016 20:53:24 -0000 Message-ID: Date: Sun, 4 Dec 2016 20:53:24 -0000 From: "Phillip Lord" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.0 (---) 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.0 (---) The documentation for "modification-hooks" on overlays says: If these functions modify the buffer, they should bind =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80=98t=E2=80=99 = around doing so, to avoid confusing the internal mechanism that calls these hooks. But as far as I can see, the only place these gets called "signal_after_change" and "signal_before_change", inhibit-modification-hooks is already specbou= nd to t, so this advice is unnecessary. Also, the documentation for inhibit-modification-hooks says: If you do want modification hooks to be run in a particular piece of code that is itself run from a modification hook, then rebind locally =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80= =98nil=E2=80=99. which suggests that, in fact, it is possible to call the modification hooks from inside another call to these functions. This is true for both emacs-25 and master. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 08:47:59 2016 Received: (at control) by debbugs.gnu.org; 5 Dec 2016 13:47:59 +0000 Received: from localhost ([127.0.0.1]:56599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDtcd-0004Dp-5i for submit@debbugs.gnu.org; Mon, 05 Dec 2016 08:47:59 -0500 Received: from mail-io0-f178.google.com ([209.85.223.178]:33417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDtcb-0004Da-3C for control@debbugs.gnu.org; Mon, 05 Dec 2016 08:47:57 -0500 Received: by mail-io0-f178.google.com with SMTP id j65so596273317iof.0 for ; Mon, 05 Dec 2016 05:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version; bh=Ma3sysnYDXYh/cc7fU8wTKm3C6S/u8DTFnky6OFbgXQ=; b=RoCN9KGCQVHHFAiVi8oK4eS06KMxF29HvDvSD39y/N3k7LradbZIg5JPq9TQnhas5B Yjr3MqqsPLCMo5R9Y7wTrsTeLn2QEDTpNV6dT3gXltrJpGRPMaoINGFyRkcsz9bOsGqm J2aBjmqR8hjH7jKA4PzA24aTeabOIoZRvCkM1PI15NJzxM/6+BrY32P/PthdHNql6API 1Akye7cNtIFeQaeRn1GR0UHb/scSXRIcTUagehlVeiTSw2Wonx/Bh6kd0xEA8tGDVSJG ia4y8iyeYBVBYvEkceSKxW1sZdfz6BYuigcj+m9psT7McRf3M/ssWEkH/y/JTO2xD7EI AM2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version; bh=Ma3sysnYDXYh/cc7fU8wTKm3C6S/u8DTFnky6OFbgXQ=; b=GmGvhGEIlKYbPnIvtn7EpF62L1RfFeoo8NFreA7J9qZbYPLhznFjukQ+2OEgeIynP6 JviQqwo4ycGINYVokPcPtTH1XuqzPiArs4wsIwJVzSVXu3uQPIUDBkBaDNJnf5Fd1zm2 ZWYJ3ie5N1zbqEOIBhWQn0k6j9AE3T86KjlYn0VOe1hEBF77NZCIURRzZIK3b8Zbxt6t 6mW5KNO01LdXdikE2xNrCk1VhjuNPRmLLna3pOYI1HAy+xqN224VLJtBBJCT7Eab8uJN HGW1HmL445vRHTDB1t+TsH8nxnVVr79/nl/drGwz3fkoH9N2drfqfRfIE+6xRNQZO5pJ BFjw== X-Gm-Message-State: AKaTC027U4+n+uq5D1DZlth3ixFXnMa3XaSvY0ROyv9vkwInPv0//Xa5dnzs6MnIlZfmPQ== X-Received: by 10.36.245.9 with SMTP id k9mr8474743ith.65.1480945671167; Mon, 05 Dec 2016 05:47:51 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id n206sm245745itg.1.2016.12.05.05.47.50 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Dec 2016 05:47:50 -0800 (PST) From: npostavs@users.sourceforge.net To: control@debbugs.gnu.org Subject: control message for bug #25111 Date: Mon, 05 Dec 2016 08:48:48 -0500 Message-ID: <87r35mfpvj.fsf@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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: 0.0 (/) retitle 25111 How modification-hooks let-bind inhibit-modification-hooks? quit From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Dec 2016 15:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Phillip Lord" Cc: 25111@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.14809520026905 (code B ref 25111); Mon, 05 Dec 2016 15:34:02 +0000 Received: (at 25111) by debbugs.gnu.org; 5 Dec 2016 15:33:22 +0000 Received: from localhost ([127.0.0.1]:57073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDvGb-0001nJ-M3 for submit@debbugs.gnu.org; Mon, 05 Dec 2016 10:33:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34627) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDvGZ-0001n5-KG for 25111@debbugs.gnu.org; Mon, 05 Dec 2016 10:33:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDvGO-000262-R9 for 25111@debbugs.gnu.org; Mon, 05 Dec 2016 10:33:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDvGO-00025r-OP; Mon, 05 Dec 2016 10:33:08 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3200 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cDvGN-0001cM-U7; Mon, 05 Dec 2016 10:33:08 -0500 Date: Mon, 05 Dec 2016 17:33:25 +0200 Message-Id: <8360myl7ay.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (phillip.lord@russet.org.uk) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) 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: -7.9 (-------) > Date: Sun, 4 Dec 2016 20:53:24 -0000 > From: "Phillip Lord" > > The documentation for "modification-hooks" on overlays says: > > If these functions modify the buffer, they should bind > ‘inhibit-modification-hooks’ to ‘t’ around doing so, to avoid > confusing the internal mechanism that calls these hooks. > > But as far as I can see, the only place these gets called > "signal_after_change" > and "signal_before_change", inhibit-modification-hooks is already specbound > to t, so this advice is unnecessary. > > Also, the documentation for inhibit-modification-hooks says: > > If you do want modification hooks to be run in a particular > piece of code that is itself run from a modification hook, then > rebind locally ‘inhibit-modification-hooks’ to ‘nil’. > > which suggests that, in fact, it is possible to call the modification > hooks from inside another call to these functions. Given these two excerpts, it seems to me that there's no inaccuracies in the manual, perhaps we just need to tell both stories in the same place or something? Or do you still think there's something incorrect in these two fragments? Thanks. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: How modification-hooks let-bind inhibit-modification-hooks? References: In-Reply-To: Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Dec 2016 17:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.148095957718438 (code B ref 25111); Mon, 05 Dec 2016 17:40:02 +0000 Received: (at 25111) by debbugs.gnu.org; 5 Dec 2016 17:39:37 +0000 Received: from localhost ([127.0.0.1]:57224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDxEn-0004nK-Bu for submit@debbugs.gnu.org; Mon, 05 Dec 2016 12:39:37 -0500 Received: from mail-oi0-f47.google.com ([209.85.218.47]:35611) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDxEl-0004my-D9 for 25111@debbugs.gnu.org; Mon, 05 Dec 2016 12:39:35 -0500 Received: by mail-oi0-f47.google.com with SMTP id b126so348468310oia.2 for <25111@debbugs.gnu.org>; Mon, 05 Dec 2016 09:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=zqFrjo7Orf6etu/CtYc8/RuoL7T6Djrb2pfLGYSc+08=; b=b5DMoe3pCTbjugs9xSFPexoMwZSugqLn+WqKA7PY8g/J/mWOXNnV96ALX/HlmHNO5A /kQ+qNjaUHX0Uf1R4Xsaqz93/HnasQkxXVbMEh+r0I5hrIwN5GDxxIAzRb4UqxNF6p2t immgWDNS0xnaKrFqpx1DOjeu+Gng60OfmYJj4Fyz03AT2bMViVPzaRKwIuV9q8yxIWGu tTOSqQajU9JMOkS/0PtqLuL2m+LL8ZwclyAO3U86bn9p/kfmB4DV1sBTjjErjUKvmRyj S18bRC5r1pI9rhvzU7lOgDvM1i4g74M83jaFi1NiiqDuEbLPxW7Wd/gjz80jNdpQQ9Uj U1Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=zqFrjo7Orf6etu/CtYc8/RuoL7T6Djrb2pfLGYSc+08=; b=Lm0U0HNiKrCnwjx5j2pO6IfHvcGcilBHgVImadW1iZD6b2fO3LUvjnwiV0+qLY8hUO LxZCgwSgR3U1baSSdbvHk4VRZefPIam/a+cO3dLD/v/I0txhwe25U5HF7lA71a1LzLh1 pSUzBjQYtwZ1fy52+bQOEIolyxgX+J4bHoJ42gh3In8nG4jB97j5fzL0YHKIj6dPdmrn vQ3ZgcT0ivRwvTJYrCkpBbjhxKpEPgUGN8RIEhxfrr6bLQ6b47XWdgyjTkGxG7CUwQ9g vVkInz9fzbdffBiXu+4kv9g5BKtWIOnVO5p4iCdmG62a3DIuIaARUSkFbTNx6kN3rAsz /jEw== X-Gm-Message-State: AKaTC02fVoVCtj6Eool802Q/um9hC3BNU72qE0VIrus4M0qFi8k92IFRs51VMw9qXeGDPHwz9gOJMjGEC5o7vA== X-Received: by 10.202.63.65 with SMTP id m62mr30875343oia.167.1480959569775; Mon, 05 Dec 2016 09:39:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.234 with HTTP; Mon, 5 Dec 2016 09:39:29 -0800 (PST) From: Noam Postavsky Date: Mon, 5 Dec 2016 12:39:29 -0500 X-Google-Sender-Auth: dtxryMXwZEJU3xN95yIxIRsnBtQ Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) 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.5 (/) On Mon, Dec 5, 2016 at 10:33 AM, Eli Zaretskii wrote: >> Date: Sun, 4 Dec 2016 20:53:24 -0000 >> From: "Phillip Lord" >> >> The documentation for "modification-hooks" on overlays says: >> >> If these functions modify the buffer, they should bind >> =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80=98t=E2=80=99= around doing so, to avoid >> confusing the internal mechanism that calls these hooks. >> >> But as far as I can see, the only place these gets called >> "signal_after_change" >> and "signal_before_change", inhibit-modification-hooks is already specbo= und >> to t, so this advice is unnecessary. >> >> Also, the documentation for inhibit-modification-hooks says: >> >> If you do want modification hooks to be run in a particular >> piece of code that is itself run from a modification hook, then >> rebind locally =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2= =80=98nil=E2=80=99. >> >> which suggests that, in fact, it is possible to call the modification >> hooks from inside another call to these functions. > > Given these two excerpts, it seems to me that there's no inaccuracies > in the manual, perhaps we just need to tell both stories in the same > place or something? Or do you still think there's something incorrect > in these two fragments? Would following the advice in the second fragment confuse the "internal mechanism" (as suggested in the first fragment) or not? From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: How modification-hooks let-bind inhibit-modification-hooks? Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Dec 2016 18:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Noam Postavsky Cc: 25111@debbugs.gnu.org, phillip.lord@russet.org.uk Reply-To: Eli Zaretskii Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.148096302623871 (code B ref 25111); Mon, 05 Dec 2016 18:38:02 +0000 Received: (at 25111) by debbugs.gnu.org; 5 Dec 2016 18:37:06 +0000 Received: from localhost ([127.0.0.1]:57251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDy8Q-0006Cw-L3 for submit@debbugs.gnu.org; Mon, 05 Dec 2016 13:37:06 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59757) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDy8P-0006CT-MV for 25111@debbugs.gnu.org; Mon, 05 Dec 2016 13:37:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDy8I-0007eq-0h for 25111@debbugs.gnu.org; Mon, 05 Dec 2016 13:37:00 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDy8H-0007em-Ti; Mon, 05 Dec 2016 13:36:57 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3410 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cDy8G-00026x-GO; Mon, 05 Dec 2016 13:36:57 -0500 Date: Mon, 05 Dec 2016 20:37:09 +0200 Message-Id: <83oa0qjk8a.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Noam Postavsky on Mon, 5 Dec 2016 12:39:29 -0500) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) 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: -7.9 (-------) > From: Noam Postavsky > Date: Mon, 5 Dec 2016 12:39:29 -0500 > Cc: Phillip Lord , 25111@debbugs.gnu.org > > >> The documentation for "modification-hooks" on overlays says: > >> > >> If these functions modify the buffer, they should bind > >> ‘inhibit-modification-hooks’ to ‘t’ around doing so, to avoid > >> confusing the internal mechanism that calls these hooks. > >> > >> But as far as I can see, the only place these gets called > >> "signal_after_change" > >> and "signal_before_change", inhibit-modification-hooks is already specbound > >> to t, so this advice is unnecessary. > >> > >> Also, the documentation for inhibit-modification-hooks says: > >> > >> If you do want modification hooks to be run in a particular > >> piece of code that is itself run from a modification hook, then > >> rebind locally ‘inhibit-modification-hooks’ to ‘nil’. > >> > >> which suggests that, in fact, it is possible to call the modification > >> hooks from inside another call to these functions. > > > > Given these two excerpts, it seems to me that there's no inaccuracies > > in the manual, perhaps we just need to tell both stories in the same > > place or something? Or do you still think there's something incorrect > > in these two fragments? > > Would following the advice in the second fragment confuse the > "internal mechanism" (as suggested in the first fragment) or not? Only if the other hooks that modify buffer, and do NOT want hooks to be run, don't bind inhibit-modification-hooks to t. AFAIU, at least. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Dec 2016 16:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25111@debbugs.gnu.org Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.148112984613583 (code B ref 25111); Wed, 07 Dec 2016 16:58:02 +0000 Received: (at 25111) by debbugs.gnu.org; 7 Dec 2016 16:57:26 +0000 Received: from localhost ([127.0.0.1]:59459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEfX4-0003X0-30 for submit@debbugs.gnu.org; Wed, 07 Dec 2016 11:57:26 -0500 Received: from mailhub-mx4.ncl.ac.uk ([128.240.234.84]:47630 helo=mailhub-mx4) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEfX1-0003Wr-EB for 25111@debbugs.gnu.org; Wed, 07 Dec 2016 11:57:24 -0500 Received: (Haraka outbound); Wed, 07 Dec 2016 16:57:22 +0000 Authentication-Results: mailhub-mx4; spf=pass smtp.mailfrom=newcastle.ac.uk X-Haraka-RcptSummary: valid=0/0 invalid=0/0 unverified=0/0 relay=1/1 norelay=0/0 X-Haraka-Relay: true Received-SPF: Pass (mailhub-mx4: domain of newcastle.ac.uk designates 10.3.193.34 as permitted sender) receiver=mailhub-mx4; identity=mailfrom; client-ip=10.3.193.34; helo=mailhub-ncl4.ncl.ac.uk; envelope-from= Received: from mailhub-ncl4.ncl.ac.uk ([10.3.193.34]) by mailhub-mx4 (DefenderMX/2.7.3) with ESMTP id BD4885A3-38E3-4524-A6C5-0AA344F2B5CA.1 envelope-from ; Wed, 07 Dec 2016 16:57:21 +0000 Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by mailhub-ncl4.ncl.ac.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cEfWz-00008e-Cg; Wed, 07 Dec 2016 16:57:21 +0000 Received: from cpc2-benw10-2-0-cust42.gate.cable.virginm.net ([77.103.60.43] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1cEfWy-0005iT-R2; Wed, 07 Dec 2016 16:57:21 +0000 From: phillip.lord@russet.org.uk (Phillip Lord) In-Reply-To: <8360myl7ay.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Dec 2016 17:33:25 +0200") Date: Wed, 07 Dec 2016 16:40:02 +0000 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-NCL-mrate: cflags=() mflags=() X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N X-Haraka-HostID: 10.3.193.34 X-Haraka-SenderAuth: 10.3.193.34 newcastle.ac.uk X-Haraka-AccessMap: connect:10 OK X-Haraka-Domain-Info: domain="russet.org.uk" last_update=284 primary_ns="dns5.planethippo.com" serial=2016022702 refresh=3600 retry=7200 expiration=1209600 minimum=86400 flags="NS_SAME_NET, MX_IS_NS, MX_SINGLE" domain="newcastle.ac.uk" last_update=0 primary_ns="dns0.ncl.ac.uk" serial=2016120712 refresh=10800 retry=3600 expiration=604800 minimum=3600 flags="SOA_UPDATE_1" X-Haraka-SubjectNonLatin: 0 X-Haraka-NonLatin: 0.458 References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> Message-Id: X-Spam-Score: 0.0 (/) 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.0 (/) Eli Zaretskii writes: >> Date: Sun, 4 Dec 2016 20:53:24 -0000 >> From: "Phillip Lord" >>=20 >> The documentation for "modification-hooks" on overlays says: >>=20 >> If these functions modify the buffer, they should bind >> =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80=98t=E2=80=99= around doing so, to avoid >> confusing the internal mechanism that calls these hooks. >>=20 >> But as far as I can see, the only place these gets called >> "signal_after_change" >> and "signal_before_change", inhibit-modification-hooks is already specbo= und >> to t, so this advice is unnecessary. >>=20 >> Also, the documentation for inhibit-modification-hooks says: >>=20 >> If you do want modification hooks to be run in a particular >> piece of code that is itself run from a modification hook, then >> rebind locally =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2= =80=98nil=E2=80=99. >>=20 >> which suggests that, in fact, it is possible to call the modification >> hooks from inside another call to these functions. > > Given these two excerpts, it seems to me that there's no inaccuracies > in the manual, perhaps we just need to tell both stories in the same > place or something? Or do you still think there's something incorrect > in these two fragments? I think that the first of these is incorrect. There is no need to bind `inhibit-modification-hooks' to `t'. More over, there may be reasons by bind `inhibit-modification-hooks' to `nil' (i.e. "If you do want modification hooks to be run..."). I am unclear whether this will "confuse the internal mechanism", since I don't know exactly what this means. It possible that the documentation should say "Mostly, you should avoid modifying the buffer on these hooks, any other functionality using these modification-hooks will not be called." The reason I ask all of this as a result of a concrete use case. yasnippet modifies the buffer in these hooks, in turn breaks my own package, lentic, which uses these hooks to respond to changes. https://github.com/joaotavora/yasnippet/issues/756 https://github.com/phillord/lentic/issues/51 Phil From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Dec 2016 15:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: phillip.lord@russet.org.uk (Phillip Lord) Cc: 25111@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.148121249614406 (code B ref 25111); Thu, 08 Dec 2016 15:55:02 +0000 Received: (at 25111) by debbugs.gnu.org; 8 Dec 2016 15:54:56 +0000 Received: from localhost ([127.0.0.1]:34724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cF128-0003kH-EG for submit@debbugs.gnu.org; Thu, 08 Dec 2016 10:54:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cF125-0003k4-W4 for 25111@debbugs.gnu.org; Thu, 08 Dec 2016 10:54:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cF11w-0007lt-78 for 25111@debbugs.gnu.org; Thu, 08 Dec 2016 10:54:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cF11w-0007ln-3m; Thu, 08 Dec 2016 10:54:44 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2367 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cF11v-00084y-CO; Thu, 08 Dec 2016 10:54:43 -0500 Date: Thu, 08 Dec 2016 17:55:09 +0200 Message-Id: <83eg1iiffm.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (phillip.lord@russet.org.uk) References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) 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: -8.0 (--------) > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: 25111@debbugs.gnu.org > Date: Wed, 07 Dec 2016 16:40:02 +0000 > > I think that the first of these is incorrect. There is no need to bind > `inhibit-modification-hooks' to `t'. More over, there may be reasons by > bind `inhibit-modification-hooks' to `nil' (i.e. "If you do want > modification hooks to be run..."). So if we envision that some hook will bind inhibit-modification-hooks to nil, then that is the reason to bind it to t in a hokk which doesn't want such hooks to be run. > It possible that the documentation should say "Mostly, you should avoid > modifying the buffer on these hooks, any other functionality using these > modification-hooks will not be called." You mean, not mention the variable at all? That'd be loss of useful information, I think. > The reason I ask all of this as a result of a concrete use > case. yasnippet modifies the buffer in these hooks, in turn breaks my > own package, lentic, which uses these hooks to respond to changes. So how would you want the manual to help avert such calamities? From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Dec 2016 17:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25111@debbugs.gnu.org Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.14813048117098 (code B ref 25111); Fri, 09 Dec 2016 17:34:01 +0000 Received: (at 25111) by debbugs.gnu.org; 9 Dec 2016 17:33:31 +0000 Received: from localhost ([127.0.0.1]:36230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFP35-0001qM-5A for submit@debbugs.gnu.org; Fri, 09 Dec 2016 12:33:31 -0500 Received: from mailgw.mycpanelcloud.co.uk ([185.116.214.125]:25085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFP32-0001q7-Qy for 25111@debbugs.gnu.org; Fri, 09 Dec 2016 12:33:29 -0500 Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id 388C2C40B9 for <25111@debbugs.gnu.org>; Fri, 9 Dec 2016 18:17:37 +0000 (GMT) X-Virus-Scanned: by SpamTitan at mycpanelcloud.co.uk Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id B4BF7C41C6 for <25111@debbugs.gnu.org>; Fri, 9 Dec 2016 18:17:35 +0000 (GMT) Received: from cloud103.planethippo.com (unknown [31.216.48.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTPS id A6E00C40C2 for <25111@debbugs.gnu.org>; Fri, 9 Dec 2016 18:17:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2Z6rTyJXSaH3N3cSx7vOGwdNKQBqoXqXX/IR/Y1DL9s=; b=yasTsAdaJmE47u7lfWleU+k4s +e5CiqyFkM1bUOTFlA7HiTl4LGu9ja49W4xFtUKdE48LEOUXRuva9BoYGd6hZP/nalzd69V9QAIF7 L/YTAqwBTiqkUwyOCIWNeAwkOup63od8wYMZk2RNwYO+ZvvUhhnueqMPAIAUIoQqsZpYYdmCxZiNQ 3I8EVYjZEOWQ5HdsK4LHvIKZ9lSdndIRKNC7ou+CCAS0XGlc8IiAr1RVyOrc86JJUqSEeWizptW3u BZbyA1QsaJ8c7rIVVWeUkas8vL6aewc6giJSRKYt3EGWB5AthGffXloFGrf7aYsYF6lREvf0cQD4d CMmbdazLw==; Received: from janus-nat-128-240-225-37.ncl.ac.uk ([128.240.225.37]:46085 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cFOnv-0007ze-Vl; Fri, 09 Dec 2016 17:17:52 +0000 From: phillip.lord@russet.org.uk (Phillip Lord) References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> Date: Fri, 09 Dec 2016 17:17:51 +0000 In-Reply-To: <83eg1iiffm.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 08 Dec 2016 17:55:09 +0200") Message-ID: <87pol1kon4.fsf@russet.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-Spam-Score: 0.0 (/) 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.0 (/) Eli Zaretskii writes: >> From: phillip.lord@russet.org.uk (Phillip Lord) >> Cc: 25111@debbugs.gnu.org >> Date: Wed, 07 Dec 2016 16:40:02 +0000 >> >> I think that the first of these is incorrect. There is no need to bind >> `inhibit-modification-hooks' to `t'. More over, there may be reasons by >> bind `inhibit-modification-hooks' to `nil' (i.e. "If you do want >> modification hooks to be run..."). > > So if we envision that some hook will bind inhibit-modification-hooks > to nil, then that is the reason to bind it to t in a hokk which > doesn't want such hooks to be run. Indeed, this is true, and it's a difficulty with the hook. I mean, it is *meant* to run when the buffer is modified and yet here is an example of where we cannot be sure that it will. >> It possible that the documentation should say "Mostly, you should avoid >> modifying the buffer on these hooks, any other functionality using these >> modification-hooks will not be called." > > You mean, not mention the variable at all? That'd be loss of useful > information, I think. > >> The reason I ask all of this as a result of a concrete use >> case. yasnippet modifies the buffer in these hooks, in turn breaks my >> own package, lentic, which uses these hooks to respond to changes. > > So how would you want the manual to help avert such calamities? My own feeling is that "inhibit-modification-hooks" should *only* be for modifications that really should not be detected by anything else. I can think of examples of this (I used to change the buffer to display a completion string to the user for instance, although I now use an "after-string" overlay property). The simplest advice makes calls to the modification hooks consistent is to say "You should not modify the buffer on these hooks". The potential solution, for instance, for yasnippet is to record the changes on after-change-function, and then change the buffer on post-command-hook. I think this would work? Is this what the manual should say? Phil From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Dec 2016 21:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: phillip.lord@russet.org.uk (Phillip Lord) Cc: 25111@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.148131781515778 (code B ref 25111); Fri, 09 Dec 2016 21:11:02 +0000 Received: (at 25111) by debbugs.gnu.org; 9 Dec 2016 21:10:15 +0000 Received: from localhost ([127.0.0.1]:36308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFSQp-00046L-1h for submit@debbugs.gnu.org; Fri, 09 Dec 2016 16:10:15 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFRns-0007Wf-1K for 25111@debbugs.gnu.org; Fri, 09 Dec 2016 15:30:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFOw5-0001PA-6h for 25111@debbugs.gnu.org; Fri, 09 Dec 2016 12:26:21 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFOw5-0001P6-3N; Fri, 09 Dec 2016 12:26:17 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4338 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cFOw4-0002nZ-CS; Fri, 09 Dec 2016 12:26:16 -0500 Date: Fri, 09 Dec 2016 19:26:46 +0200 Message-Id: <83bmwlggix.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87pol1kon4.fsf@russet.org.uk> (phillip.lord@russet.org.uk) References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) 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: -8.0 (--------) > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: 25111@debbugs.gnu.org > Date: Fri, 09 Dec 2016 17:17:51 +0000 > > > So how would you want the manual to help avert such calamities? > > > My own feeling is that "inhibit-modification-hooks" should *only* be for > modifications that really should not be detected by anything else. I can > think of examples of this (I used to change the buffer to display a > completion string to the user for instance, although I now use an > "after-string" overlay property). > > The simplest advice makes calls to the modification hooks consistent is > to say "You should not modify the buffer on these hooks". The potential > solution, for instance, for yasnippet is to record the changes on > after-change-function, and then change the buffer on > post-command-hook. I think this would work? Is this what the manual > should say? IMO, the manual should advise the safe practices, and then tell how to behave if the code really needs to play it less safe. The former would be what you say above, I think. But since we know there are packages out there that don't choose the safe approach, we should cover those as well. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2016 22:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25111@debbugs.gnu.org Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.14814942899100 (code B ref 25111); Sun, 11 Dec 2016 22:12:01 +0000 Received: (at 25111) by debbugs.gnu.org; 11 Dec 2016 22:11:29 +0000 Received: from localhost ([127.0.0.1]:38501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGCLA-0002Mh-Sa for submit@debbugs.gnu.org; Sun, 11 Dec 2016 17:11:29 -0500 Received: from mailgw.mycpanelcloud.co.uk ([185.116.214.205]:36873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGCL8-0002MT-D2 for 25111@debbugs.gnu.org; Sun, 11 Dec 2016 17:11:28 -0500 Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id 97BEFC4702 for <25111@debbugs.gnu.org>; Sun, 11 Dec 2016 23:11:03 +0000 (GMT) X-Virus-Scanned: by SpamTitan at mycpanelcloud.co.uk Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id 9915BC4666 for <25111@debbugs.gnu.org>; Sun, 11 Dec 2016 23:10:59 +0000 (GMT) Received: from cloud103.planethippo.com (unknown [31.216.48.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTPS id 750B3C45FB for <25111@debbugs.gnu.org>; Sun, 11 Dec 2016 23:10:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From:Sender :Reply-To: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=7QEUhlLC7dPEb+X9rJZCff8zOn6vy4utxnL3tc/jWTg=; b=E7/+7ta2+2lLnOK6Bs5q/GPjFW kzgQrkmjICqPEeoNnLwXHrYeUiTm3FynQV8jF4ixK+epuIwoVd51zcueHfu474leTfbleLVtyW4MH iypPehWDW6lagD0360qznIdv8a2wFCjOg5Sdn05ljVDLxy+a5uaRCY+KR5j/q1+rfnGiVeHQZudti Os50A2hkOPu30L/rZdfNNkwBKuNa7NR0vDquzwucgzKac9sdwrS7YgNi9W4wrHFsycV3lfr1VEW/c c7s2J+ZY8jwYtKDxgQHBAdWh9ncbwG6f/aJHXDhd0l1lc4hwUYyvT3x3FpI3B8+KGOSuAFk6mtIQ7 rjTwaLEw==; Received: from cpc2-benw10-2-0-cust42.gate.cable.virginm.net ([77.103.60.43]:49106 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cGCKy-001MBf-2r; Sun, 11 Dec 2016 22:11:16 +0000 From: phillip.lord@russet.org.uk (Phillip Lord) References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> Date: Sun, 11 Dec 2016 22:11:14 +0000 In-Reply-To: <83bmwlggix.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Dec 2016 19:26:46 +0200") Message-ID: <878trmxgjh.fsf@russet.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-Spam-Score: 0.0 (/) 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.0 (/) Eli Zaretskii writes: >> From: phillip.lord@russet.org.uk (Phillip Lord) >> Cc: 25111@debbugs.gnu.org >> Date: Fri, 09 Dec 2016 17:17:51 +0000 >> >> My own feeling is that "inhibit-modification-hooks" should *only* be for >> modifications that really should not be detected by anything else. I can >> think of examples of this (I used to change the buffer to display a >> completion string to the user for instance, although I now use an >> "after-string" overlay property). >>=20 >> The simplest advice makes calls to the modification hooks consistent is >> to say "You should not modify the buffer on these hooks". The potential >> solution, for instance, for yasnippet is to record the changes on >> after-change-function, and then change the buffer on >> post-command-hook. I think this would work? Is this what the manual >> should say? > > IMO, the manual should advise the safe practices, and then tell how to > behave if the code really needs to play it less safe. The former > would be what you say above, I think. But since we know there are > packages out there that don't choose the safe approach, we should > cover those as well. So, instead of this: If these functions modify the buffer, they should bind =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80=98t=E2=80=99 ar= ound doing so, to avoid confusing the internal mechanism that calls these hooks. We could have: These functions should avoid unnecessarily modifying the buffer. Emacs binds 'inhibit-modification-hooks' to `t' during their evaluation, which means that any modifications will not be signalled to other hook functions listening for them. Perhaps a better solution would be: These functions should avoid unnecessarily modifying the buffer; see Change Hooks for further details. Then a new paragraph can be added to the Change Hooks section talking about the complexity of modifying buffers on these hooks, with alternatives. I am happy to draft something if you wish. Phil From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Dec 2016 16:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: phillip.lord@russet.org.uk (Phillip Lord) Cc: 25111@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.14815587683283 (code B ref 25111); Mon, 12 Dec 2016 16:07:01 +0000 Received: (at 25111) by debbugs.gnu.org; 12 Dec 2016 16:06:08 +0000 Received: from localhost ([127.0.0.1]:39411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGT79-0000qs-NU for submit@debbugs.gnu.org; Mon, 12 Dec 2016 11:06:07 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGT78-0000qH-4D for 25111@debbugs.gnu.org; Mon, 12 Dec 2016 11:06:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cGT6z-0007YN-5g for 25111@debbugs.gnu.org; Mon, 12 Dec 2016 11:06:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGT6z-0007YH-2V; Mon, 12 Dec 2016 11:05:57 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4666 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cGT6y-00046i-Cy; Mon, 12 Dec 2016 11:05:56 -0500 Date: Mon, 12 Dec 2016 18:06:34 +0200 Message-Id: <83lgvlcet1.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <878trmxgjh.fsf@russet.org.uk> (phillip.lord@russet.org.uk) References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) 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: -8.1 (--------) > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: 25111@debbugs.gnu.org > Date: Sun, 11 Dec 2016 22:11:14 +0000 > > So, instead of this: > > If these functions modify the buffer, they should bind > ‘inhibit-modification-hooks’ to ‘t’ around doing so, to avoid > confusing the internal mechanism that calls these hooks. > > > We could have: > > These functions should avoid unnecessarily modifying the buffer. > Emacs binds 'inhibit-modification-hooks' to `t' during their > evaluation, which means that any modifications will not be signalled > to other hook functions listening for them. > > > Perhaps a better solution would be: > > > These functions should avoid unnecessarily modifying the buffer; see > Change Hooks for further details. > > > Then a new paragraph can be added to the Change Hooks section talking > about the complexity of modifying buffers on these hooks, with > alternatives. > > I am happy to draft something if you wish. Sure, please do. Thanks. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: How modification-hooks let-bind inhibit-modification-hooks? References: In-Reply-To: Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 19:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Phillip Lord Cc: Eli Zaretskii , 25111@debbugs.gnu.org Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.148908805414048 (code B ref 25111); Thu, 09 Mar 2017 19:35:01 +0000 Received: (at 25111) by debbugs.gnu.org; 9 Mar 2017 19:34:14 +0000 Received: from localhost ([127.0.0.1]:48050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm3pG-0003eW-G6 for submit@debbugs.gnu.org; Thu, 09 Mar 2017 14:34:14 -0500 Received: from mail-ot0-f175.google.com ([74.125.82.175]:34219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm3pE-0003eG-Ht for 25111@debbugs.gnu.org; Thu, 09 Mar 2017 14:34:12 -0500 Received: by mail-ot0-f175.google.com with SMTP id o24so63070134otb.1 for <25111@debbugs.gnu.org>; Thu, 09 Mar 2017 11:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=H4omAFqfFqddR5LdjcqUr0CplokaRl838YJx9V8tD58=; b=c5QhN4OvenzSvzy0QZAVXZneZw+wnjAciHfueAI85i6WfFfXRr0FUz5hyBO7G4UhGP CCcJjOcGEC1AoFBi2lAzZQ8jFNvr1zia5yKRuh9TDV018gabIri8stAfEQETxrmyEk7O UuhdzFkF/A66uXa8/p/20O3GiQDR8SHFo2LrddGVUSg6f/8NXh0sbK1hMWJaDUvg3k16 txKi5JJhUF9dwmf2uw7dMNn3/5l9FuPixizSUXZD2ugIO+CONX2LBkQmlAYn1DVMGvQU zytHcBHPLSJ8ZU0KWiSJ9zKz3HuRubUpLXpU2aPpxiHaqccedlcPcHUVfrMIw7+S/LVC GvpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=H4omAFqfFqddR5LdjcqUr0CplokaRl838YJx9V8tD58=; b=c4Hd5rljId8Be2oFOmBMtt6cCF68aE8xr1POpqKI+0Pv3H9xWNFLoYjeDdejSuDubR WLN1mwb7IAyrKuxjhQIhoSEPHbSZfn/e8je+B0NtBbM87VY0kQec54H49cRGMpIwjO8m KKXrj3Mcd6Xxqp0DvDGRGrufwQnc27AqvRcaWoKC47iyOI5J1CiU92Ky/3vctHlxCMKU Vy3j0RmiZTrMcq9xVJN76c5gYxWtnXhkTZ/DwMeWUfkS6OHMueJuevrcJw8q2rSw6rNZ i9IIVei85IOCFQHpCKr7NLn2iXPr8jj8UCRkAm6XJjEtf/ZFGRVOLBG3aAlOmr67yqX0 1a0A== X-Gm-Message-State: AFeK/H3r7uOBQilo3A/gBY/pgxVHCZSha7ohvnNVB5qWNhXuuxUWINLuBu798SNwONoZHvQS1i4BkdTdkxsC1g== X-Received: by 10.157.42.39 with SMTP id t36mr9112593ota.79.1489088046494; Thu, 09 Mar 2017 11:34:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.80.172 with HTTP; Thu, 9 Mar 2017 11:34:06 -0800 (PST) From: Noam Postavsky Date: Thu, 9 Mar 2017 14:34:06 -0500 X-Google-Sender-Auth: W7aQ4P1fVeNqXgDYlrxTNFBfQbc Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.7 (/) 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 (/) On Wed, Dec 7, 2016 at 11:40 AM, Phillip Lord wrote: > > The reason I ask all of this as a result of a concrete use > case. yasnippet modifies the buffer in these hooks, in turn breaks my > own package, lentic, which uses these hooks to respond to changes. > > > https://github.com/joaotavora/yasnippet/issues/756 > https://github.com/phillord/lentic/issues/51 By the way, text-clone--maintain in subr.el seems to have the same problem. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 May 2019 20:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Noam Postavsky Cc: 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155829788523276 (code B ref 25111); Sun, 19 May 2019 20:32:02 +0000 Received: (at 25111) by debbugs.gnu.org; 19 May 2019 20:31:25 +0000 Received: from localhost ([127.0.0.1]:35627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSSSr-00063M-0t for submit@debbugs.gnu.org; Sun, 19 May 2019 16:31:25 -0400 Received: from colin.muc.de ([193.149.48.1]:19821 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hSSSo-000637-Tx for 25111@debbugs.gnu.org; Sun, 19 May 2019 16:31:23 -0400 Received: (qmail 4766 invoked by uid 3782); 19 May 2019 20:31:20 -0000 Received: from acm.muc.de (p2E5D561D.dip0.t-ipconnect.de [46.93.86.29]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 May 2019 22:31:19 +0200 Received: (qmail 5936 invoked by uid 1000); 19 May 2019 20:31:19 -0000 Date: Sun, 19 May 2019 20:31:19 +0000 Message-ID: <20190519203119.GA5309@ACM> References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83lgvlcet1.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Eli and Noam. On Mon, Dec 12, 2016 at 18:06:34 +0200, Eli Zaretskii wrote: > > From: phillip.lord@russet.org.uk (Phillip Lord) > > Cc: 25111@debbugs.gnu.org > > Date: Sun, 11 Dec 2016 22:11:14 +0000 > > So, instead of this: > > If these functions modify the buffer, they should bind > > ‘inhibit-modification-hooks’ to ‘t’ around doing so, to avoid > > confusing the internal mechanism that calls these hooks. > > We could have: > > These functions should avoid unnecessarily modifying the buffer. > > Emacs binds 'inhibit-modification-hooks' to `t' during their > > evaluation, which means that any modifications will not be signalled > > to other hook functions listening for them. > > Perhaps a better solution would be: > > These functions should avoid unnecessarily modifying the buffer; see > > Change Hooks for further details. > > Then a new paragraph can be added to the Change Hooks section talking > > about the complexity of modifying buffers on these hooks, with > > alternatives. > > I am happy to draft something if you wish. > Sure, please do. > Thanks. OK, it was a while ago, and I'm not Phillip, but I recently got caught out with the inaccurate documentation of inhibit-modification-hooks, so I suggest the following, to get the discussion rolling again: diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index a2ed4b3891..b88702f2a2 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -1743,9 +1743,17 @@ Overlay Properties length is the number of characters deleted, and the post-change beginning and end are equal.) -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +@c If these functions modify the buffer, they should bind +@c @code{inhibit-modification-hooks} to @code{t} around doing so, to +@c avoid confusing the internal mechanism that calls these hooks. + +When these functions are called, @code{inhibit-modification-hooks} is +bound to non-@code{nil}. If the functions modify the buffer, you +might want to bind @code{inhibit-modification-hooks} to nil, so as to +cause the change hooks to run for these modifications. @xref{Change +Hooks}. However, doing this can sometimes confuse the internal +mechanism that calls all these hooks, leading, for example, to calling +them recursively, which is usually unwanted. Text properties also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Special Properties}). diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi index 278bc3c268..fd4338ecdb 100644 --- a/doc/lispref/text.texi +++ b/doc/lispref/text.texi @@ -3621,9 +3621,14 @@ Special Properties hook will only be run when removing some characters, replacing them with others, or changing their text-properties. -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +@c If these functions modify the buffer, they should bind +@c @code{inhibit-modification-hooks} to @code{t} around doing so, to +@c avoid confusing the internal mechanism that calls these hooks. + +When Emacs calls these functions, @code{inhibit-modification-hooks} is +set to @code{nil}. If the functions modify the buffer, you should +consider binding this variable to non-@code{nil}, to avoid confusing +the internal mechanism that calls these hooks. @xref{Change Hooks}. Overlays also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Overlay Properties}). -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 May 2019 12:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155878799511539 (code B ref 25111); Sat, 25 May 2019 12:40:04 +0000 Received: (at 25111) by debbugs.gnu.org; 25 May 2019 12:39:55 +0000 Received: from localhost ([127.0.0.1]:48345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUVxq-000302-PF for submit@debbugs.gnu.org; Sat, 25 May 2019 08:39:55 -0400 Received: from mail-it1-f174.google.com ([209.85.166.174]:54402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUVxo-0002zl-KI for 25111@debbugs.gnu.org; Sat, 25 May 2019 08:39:53 -0400 Received: by mail-it1-f174.google.com with SMTP id h20so20158106itk.4 for <25111@debbugs.gnu.org>; Sat, 25 May 2019 05:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=uf5XYfF8WiCY0eU8xQG8im59dlRrinCL9MBYhMtztvA=; b=il2nmYyktVWBB44D9xDVG3e/VjyxpIgc5HwC710CBS9eOcggj0J8Rj7gLXIZif6t7f hdf0NMK8VlF+E03AwszBEUwmV+QUHlCzj+6RY9ril472B7YiKTgIOdUD4oSkonU1kRTn xtuvXpklvVnCcXUrdfnuoxt9Jt/7/4FPAPDrhxdVqJVh6TP8DHPO4b3FnaZrqxkG5Ygq 3ubgc+iOaQb+lfqo1CCVYtR1Pd1TwB8sPCeQXElaZZeMMEqSQpf/IoTfTiB8O251WrSK YGlOJHjR3w3PPisNjx4tsvTbKMQmr/qMYQMFzM3/lJlvS29IbPVx/DGPhFmcCKEe2vL6 m7LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=uf5XYfF8WiCY0eU8xQG8im59dlRrinCL9MBYhMtztvA=; b=ESAXQKxakhuIG76z3o2ZV4A4iD0TV+5OTcVOxi8Fqn1Tfl1MkAdDWbzV6J6TAj15YW VqR01C4tBpL3q/OoVujyEjF3RhnFV8M4n7R4MuZZ90Nrq6zKQgTeYCGUKJ83OnvCcRBI gL1j+P2ABXqUXyX6mm+cUi8CMumQn4/0BLBijAzug4yRHXteBYYIxf3WBK1l0FIj0VBs 7UEiBRC1zPftAC+/SNKcudF0/i37FHM4YCj5V9YVYQmmdfGd3e/DRCgLCbVKt4CaeQHY gkFauq/mCr47FMJT30qGIDgTVDOoCPUKtd1jXCTxry6O2Bcayaq/GAn9MW14sijr/bYk 8WGw== X-Gm-Message-State: APjAAAUjjfhlFgDthcMfufsKkvXk8voC0tagy1cw6/HyNHhiQ/suoO/3 shc8emhAtkUqOWRDdcdiIGL3+YOF X-Google-Smtp-Source: APXvYqwFXASWn8Fyj0SwcicJ7FBlWQZQV4UlSWaZa13d2ulXAtpYEY++50QUfxpasxvi4PPODsFaSg== X-Received: by 2002:a24:4cd2:: with SMTP id a201mr23721349itb.26.1558787986949; Sat, 25 May 2019 05:39:46 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id k7sm1760569ioh.36.2019.05.25.05.39.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 25 May 2019 05:39:45 -0700 (PDT) From: Noam Postavsky References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> Date: Sat, 25 May 2019 08:39:39 -0400 In-Reply-To: <20190519203119.GA5309@ACM> (Alan Mackenzie's message of "Sun, 19 May 2019 20:31:19 +0000") Message-ID: <87y32u908k.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) 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.0 (-) --=-=-= Content-Type: text/plain Alan Mackenzie writes: > @@ -1743,9 +1743,17 @@ Overlay Properties > However, doing this can sometimes confuse the internal > +mechanism that calls all these hooks, leading, for example, to calling > +them recursively, which is usually unwanted. > @@ -3621,9 +3621,14 @@ Special Properties > +When Emacs calls these functions, @code{inhibit-modification-hooks} is > +set to @code{nil}. As Phillip mentioned in the OP, Emacs in fact binds it to t. > If the functions modify the buffer, you should > +consider binding this variable to non-@code{nil}, to avoid confusing > +the internal mechanism that calls these hooks. @xref{Change Hooks}. I find this "confusing the internal mechanism" thing unhelpful, how about this instead: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Clarify-elisp-ref-for-inhibit-modification-hooks-Bug.patch Content-Description: patch >From 568e640f962cd9a59d695351ded11c4a8e781f06 Mon Sep 17 00:00:00 2001 From: Alan Mackenzie Date: Sun, 19 May 2019 20:31:19 +0000 Subject: [PATCH] Clarify elisp ref for inhibit-modification-hooks (Bug#25111) * doc/lispref/display.texi (Overlay Properties): * doc/lispref/text.texi (Special Properties) (Change Hooks): Explain that inhibit-modification-hooks is bound to t while executing change hooks, and suggest binding to nil with suitable precautions when modifying buffer from a change hook. Co-authored-by: Noam Postavsky --- doc/lispref/display.texi | 9 ++++++--- doc/lispref/text.texi | 12 ++++++++---- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index b07999432c..f7140f444e 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -1708,9 +1708,12 @@ Overlay Properties length is the number of characters deleted, and the post-change beginning and end are equal.) -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +When these functions are called, @code{inhibit-modification-hooks} is +bound to non-@code{nil}. If the functions modify the buffer, you +might want to bind @code{inhibit-modification-hooks} to nil, so as to +cause the change hooks to run for these modifications. However, doing +this may call your own change hook recursively, so be sure to prepare +for that. @xref{Change Hooks}. Text properties also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Special Properties}). diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi index f3d222b708..5954161fcf 100644 --- a/doc/lispref/text.texi +++ b/doc/lispref/text.texi @@ -3514,9 +3514,10 @@ Special Properties hook will only be run when removing some characters, replacing them with others, or changing their text-properties. -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +When Emacs calls these functions, @code{inhibit-modification-hooks} is +set to non-@code{nil}. If the functions modify the buffer, you should +consider binding this variable to @code{nil}, but in that case you +must be prepared for recursive calls. @xref{Change Hooks}. Overlays also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Overlay Properties}). @@ -5093,5 +5094,8 @@ Change Hooks a modification hook does not cause other modification hooks to be run. If you do want modification hooks to be run in a particular piece of code that is itself run from a modification hook, then rebind locally -@code{inhibit-modification-hooks} to @code{nil}. +@code{inhibit-modification-hooks} to @code{nil}. However, doing this +may cause recursive calls to the modification hooks, so be sure to +prepare for that (for example, by binding some variable which tells +your hook to do nothing). @end defvar -- 2.11.0 --=-=-=-- From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 May 2019 13:45:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Noam Postavsky Cc: Eli Zaretskii , 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155879185718220 (code B ref 25111); Sat, 25 May 2019 13:45:04 +0000 Received: (at 25111) by debbugs.gnu.org; 25 May 2019 13:44:17 +0000 Received: from localhost ([127.0.0.1]:48447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUWy9-0004jn-G1 for submit@debbugs.gnu.org; Sat, 25 May 2019 09:44:17 -0400 Received: from colin.muc.de ([193.149.48.1]:31556 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hUWy6-0004jX-Ks for 25111@debbugs.gnu.org; Sat, 25 May 2019 09:44:15 -0400 Received: (qmail 10877 invoked by uid 3782); 25 May 2019 13:44:08 -0000 Received: from acm.muc.de (p4FE15042.dip0.t-ipconnect.de [79.225.80.66]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 25 May 2019 15:44:07 +0200 Received: (qmail 10920 invoked by uid 1000); 25 May 2019 13:44:07 -0000 Date: Sat, 25 May 2019 13:44:07 +0000 Message-ID: <20190525134407.GA10864@ACM> References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y32u908k.fsf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Noam. On Sat, May 25, 2019 at 08:39:39 -0400, Noam Postavsky wrote: > Alan Mackenzie writes: > > @@ -1743,9 +1743,17 @@ Overlay Properties > > However, doing this can sometimes confuse the internal > > +mechanism that calls all these hooks, leading, for example, to calling > > +them recursively, which is usually unwanted. > > @@ -3621,9 +3621,14 @@ Special Properties > > +When Emacs calls these functions, @code{inhibit-modification-hooks} is > > +set to @code{nil}. > As Phillip mentioned in the OP, Emacs in fact binds it to t. Are you sure? We're talking here about the text property (in which I think inhibit-modification-hooks IS at nil) as opposed to the overlay property (where inhibit-modification-hooks is bound to t). I admit just to having examined the source code rather than actually trying it out. But in verify_interval_modification in textprop.c, near the end, we have: if (!inhibit_modification_hooks) { hooks = Fnreverse (hooks); while (! NILP (hooks)) { call_mod_hooks (Fcar (hooks), make_fixnum (start), make_fixnum (end)); hooks = Fcdr (hooks); } } . Here, mod_hooks is a list of modification-hooks combined with positions. call_mod_hooks only gets called when inhibit-modification-hooks is nil. call_mod_hooks just calls the hooks, without binding i-m-h. Are you really sure? I'll answer the rest of your post later, I've got a lot on in Real Life at the moment. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 May 2019 13:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Noam Postavsky Cc: acm@muc.de, 25111@debbugs.gnu.org, phillip.lord@russet.org.uk Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155879221018868 (code B ref 25111); Sat, 25 May 2019 13:51:01 +0000 Received: (at 25111) by debbugs.gnu.org; 25 May 2019 13:50:10 +0000 Received: from localhost ([127.0.0.1]:48461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUX3p-0004uF-LR for submit@debbugs.gnu.org; Sat, 25 May 2019 09:50:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUX3n-0004tn-0O for 25111@debbugs.gnu.org; Sat, 25 May 2019 09:50:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUX3g-0003SX-5a; Sat, 25 May 2019 09:50:01 -0400 Received: from [176.228.60.248] (port=4062 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUX3f-0004gC-IA; Sat, 25 May 2019 09:49:59 -0400 Date: Sat, 25 May 2019 16:49:59 +0300 Message-Id: <83d0k64pa0.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87y32u908k.fsf@gmail.com> (message from Noam Postavsky on Sat, 25 May 2019 08:39:39 -0400) References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Noam Postavsky > Cc: Eli Zaretskii , 25111@debbugs.gnu.org, Phillip Lord > Date: Sat, 25 May 2019 08:39:39 -0400 > > I find this "confusing the internal mechanism" thing unhelpful, how > about this instead: Fine with me (although I'm not Alan), but please avoid saying the same thing more than once. It is better to describe the issue in one place, and then have the N-1 other places have a cross-reference to that one place. Thanks. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 May 2019 14:38:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155879502524713 (code B ref 25111); Sat, 25 May 2019 14:38:03 +0000 Received: (at 25111) by debbugs.gnu.org; 25 May 2019 14:37:05 +0000 Received: from localhost ([127.0.0.1]:49332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUXnF-0006QW-0I for submit@debbugs.gnu.org; Sat, 25 May 2019 10:37:05 -0400 Received: from mail-it1-f182.google.com ([209.85.166.182]:38841) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUXnD-0006Q3-5n for 25111@debbugs.gnu.org; Sat, 25 May 2019 10:37:03 -0400 Received: by mail-it1-f182.google.com with SMTP id i63so17999394ita.3 for <25111@debbugs.gnu.org>; Sat, 25 May 2019 07:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=lAw61V5YPlrs+Bw1SsPS3trKyTQYr0zw72ZOEZa7R9U=; b=jfZl6TR5Gg4fE+kARvonoO4h1t2q5Z4oPhxqPGrO4Z7NHqZZ6f6bLoxCz8hWG/OE5m fHJ7qBe3rXV27vB1C1yQc3FOA1ZjcPIdvAB83DtGmzETrGbtg+tmwP6TS6E+uviu6azi DIQTo5t8IsiTQ18HjJhT1/eV+0r3mTuLBqo5Ar3XzrlkF9ETrDseuKCEP/r3u6cm9D9i 9g807d8yDQSPTmzPeX+0TKuS4n+Lehb4kYYqVKvgxJjO6Q+yGln+AXLFBIdRu6Vcafr2 nUmSNYkPQsQyaY2lSwZwc1MSRbJsd44P2A7QV0p72JnUvSUuREkeQa4ywN61X2V+qHWd lDCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=lAw61V5YPlrs+Bw1SsPS3trKyTQYr0zw72ZOEZa7R9U=; b=UTeFc0Lftj3YQGqZzFFVP0/g+VIOony1Agwg2bZJ72pLAAOKHl7HMZZyUZ88nqaVME YuxeqaOiDVcGwYyWL3b8cCmB6DQUF1RBXvcYX4cqW5pvVR8VYCXidVBF7zvjcm4ycSmV UcMl2KTB+CpANUaB2J4Cu+o3t550hDIt68co3vkn0xdYPDlt5DeX6jlw4OOP4bf/Tn6G 3MKdpj0qRs+PdzL9Uei4IUSzJKxsYtujS+dwGJyk/k3Jk0aR7hyKHz2T13NtfsCTTxRA 8fP5i96o8APUBvz85q+fmTPASVsqph7Bb2LDvYQChX71rB5Cl36OxPBsvAWlbJ7GVg8V avSQ== X-Gm-Message-State: APjAAAXHPgl1S5SYFIejN6UbYAFoQmgzBP+jN57KbDpQcUa6KdSH7Tka moFk6pQWD8XBUAcwN9TyA3w= X-Google-Smtp-Source: APXvYqxappfRR9ohRNLy02Z2oKF+oq3pIRcIZ8/wuVK940OZ3ErqxUQfyS3yXx7dlW29KE8NOMUD5A== X-Received: by 2002:a24:4415:: with SMTP id o21mr21697476ita.143.1558795017568; Sat, 25 May 2019 07:36:57 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id q10sm1957155ioi.52.2019.05.25.07.36.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 25 May 2019 07:36:56 -0700 (PDT) From: Noam Postavsky References: <8360myl7ay.fsf@gnu.org> <87wpfbpual.fsf@russet.org.uk> <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> Date: Sat, 25 May 2019 10:36:55 -0400 In-Reply-To: <20190525134407.GA10864@ACM> (Alan Mackenzie's message of "Sat, 25 May 2019 13:44:07 +0000") Message-ID: <87sgt28ut4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) 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.0 (-) --=-=-= Content-Type: text/plain Alan Mackenzie writes: >>> @@ -3621,9 +3621,14 @@ Special Properties > >>> +When Emacs calls these functions, @code{inhibit-modification-hooks} is >>> +set to @code{nil}. > >> As Phillip mentioned in the OP, Emacs in fact binds it to t. > > Are you sure? We're talking here about the text property (in which I > think inhibit-modification-hooks IS at nil) as opposed to the overlay > property (where inhibit-modification-hooks is bound to t). Oh, you're quite right. Here's some test code: --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=bug-25111-binding-of-inhibit-mod-hooks.el Content-Description: testing inhibit-modification-hooks binding (defun mod-hook-text-prop (&rest args) (message "mod-hook-text-prop %S, inhibit? %S" args inhibit-modification-hooks)) (defun mod-hook-ov-prop (&rest args) (message "mod-hook-ov-prop %S, inhibit? %S" args inhibit-modification-hooks)) (defun mod-hook-change-fun (&rest args) (message "mod-hook-change-fun %S, inhibit? %S" args inhibit-modification-hooks)) (with-current-buffer (get-buffer-create "*test*") (insert (propertize "foo\n" 'modification-hooks '(mod-hook-text-prop))) (let ((ov (make-overlay (point-min) (point-max) ))) (overlay-put ov 'modification-hooks '(mod-hook-ov-prop))) (setq-local before-change-functions '(mod-hook-change-fun)) (setq-local after-change-functions '(mod-hook-change-fun)) (goto-char (point-min)) (delete-char 3) (insert "bar")) --=-=-= Content-Type: text/plain Which produces this: mod-hook-text-prop (1 4), inhibit? nil mod-hook-change-fun (1 4), inhibit? t mod-hook-ov-prop (# nil 1 4), inhibit? t mod-hook-change-fun (1 1 3), inhibit? t mod-hook-ov-prop (# t 1 1 3), inhibit? t mod-hook-change-fun (1 1), inhibit? t mod-hook-change-fun (1 4 0), inhibit? t I think we need to emphasize the difference in this case, it's rather confusing. > I'll answer the rest of your post later, I've got a lot on in Real Life > at the moment. No rush. I've updated the patch based on your and Eli's feedback. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Clarify-elisp-ref-for-inhibit-modification-hooks-Bug.patch Content-Description: patch >From 7f6453596b7753af7704eaac7f27ebba8d03cfc4 Mon Sep 17 00:00:00 2001 From: Alan Mackenzie Date: Sun, 19 May 2019 20:31:19 +0000 Subject: [PATCH] Clarify elisp ref for inhibit-modification-hooks (Bug#25111) * doc/lispref/display.texi (Overlay Properties): * doc/lispref/text.texi (Change Hooks): Explain that inhibit-modification-hooks is bound to t while executing change hooks, and suggest binding to nil with suitable precautions when modifying buffer from a change hook. (Special Properties): Emphasize that inhibit-modification-hooks is left set to nil when executing text property change hooks. Co-authored-by: Noam Postavsky --- doc/lispref/display.texi | 6 +++--- doc/lispref/text.texi | 12 ++++++++---- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index b07999432c..59d02d540a 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -1708,9 +1708,9 @@ Overlay Properties length is the number of characters deleted, and the post-change beginning and end are equal.) -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +Similar to change hooks, when these functions are called, +@code{inhibit-modification-hooks} is bound to @code{t}. @xref{Change +Hooks}. Text properties also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Special Properties}). diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi index f3d222b708..c935cfe49b 100644 --- a/doc/lispref/text.texi +++ b/doc/lispref/text.texi @@ -3514,9 +3514,10 @@ Special Properties hook will only be run when removing some characters, replacing them with others, or changing their text-properties. -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +When Emacs calls these functions, @code{inhibit-modification-hooks} is +set to @code{nil}, unlike for change hooks. When writing a function +which modifies the buffer, consider binding it @code{t}, to avoid +recursive calls. @xref{Change Hooks}. Overlays also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Overlay Properties}). @@ -5093,5 +5094,8 @@ Change Hooks a modification hook does not cause other modification hooks to be run. If you do want modification hooks to be run in a particular piece of code that is itself run from a modification hook, then rebind locally -@code{inhibit-modification-hooks} to @code{nil}. +@code{inhibit-modification-hooks} to @code{nil}. However, doing this +may cause recursive calls to the modification hooks, so be sure to +prepare for that (for example, by binding some variable which tells +your hook to do nothing). @end defvar -- 2.11.0 --=-=-=-- From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 May 2019 14:32:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Noam Postavsky Cc: Eli Zaretskii , 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155896748125570 (code B ref 25111); Mon, 27 May 2019 14:32:03 +0000 Received: (at 25111) by debbugs.gnu.org; 27 May 2019 14:31:21 +0000 Received: from localhost ([127.0.0.1]:53725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVGem-0006e5-VI for submit@debbugs.gnu.org; Mon, 27 May 2019 10:31:21 -0400 Received: from colin.muc.de ([193.149.48.1]:61576 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hVGek-0006bn-VI for 25111@debbugs.gnu.org; Mon, 27 May 2019 10:31:19 -0400 Received: (qmail 86435 invoked by uid 3782); 27 May 2019 14:31:11 -0000 Received: from acm.muc.de (p4FE15E6C.dip0.t-ipconnect.de [79.225.94.108]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 27 May 2019 16:31:09 +0200 Received: (qmail 6083 invoked by uid 1000); 27 May 2019 14:31:09 -0000 Date: Mon, 27 May 2019 14:31:09 +0000 Message-ID: <20190527143109.GA5863@ACM> References: <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sgt28ut4.fsf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Noam. On Sat, May 25, 2019 at 10:36:55 -0400, Noam Postavsky wrote: > Alan Mackenzie writes: > >>> @@ -3621,9 +3621,14 @@ Special Properties > >>> +When Emacs calls these functions, @code{inhibit-modification-hooks} is > >>> +set to @code{nil}. > >> As Phillip mentioned in the OP, Emacs in fact binds it to t. > > Are you sure? We're talking here about the text property (in which I > > think inhibit-modification-hooks IS at nil) as opposed to the overlay > > property (where inhibit-modification-hooks is bound to t). > Oh, you're quite right. Here's some test code: [ .... ] > Which produces this: > mod-hook-text-prop (1 4), inhibit? nil > mod-hook-change-fun (1 4), inhibit? t > mod-hook-ov-prop (# nil 1 4), inhibit? t > mod-hook-change-fun (1 1 3), inhibit? t > mod-hook-ov-prop (# t 1 1 3), inhibit? t > mod-hook-change-fun (1 1), inhibit? t > mod-hook-change-fun (1 4 0), inhibit? t > I think we need to emphasize the difference in this case, it's rather > confusing. Alternatively, we could perhaps regard the first of these results (for modification-hooks) as a bug in the code, which seems like it ought to be binding inhibit-modification-hooks to non-nil like the others. Maybe we should amend the code, even though this would be a jarring incompatibility with previous Emacs versions. Eli? [ .... ] > I've updated the patch based on your and Eli's feedback. Yes, I agree that "confusing the internal mechanism" is unhelpful here. Thanks for getting rid of it. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Jun 2019 19:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Phillip Lord , Noam Postavsky , 25111@debbugs.gnu.org Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155958936129458 (code B ref 25111); Mon, 03 Jun 2019 19:16:01 +0000 Received: (at 25111) by debbugs.gnu.org; 3 Jun 2019 19:16:01 +0000 Received: from localhost ([127.0.0.1]:43162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXsR6-0007f3-Oi for submit@debbugs.gnu.org; Mon, 03 Jun 2019 15:16:01 -0400 Received: from colin.muc.de ([193.149.48.1]:15207 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hXsR4-0007eu-3Z for 25111@debbugs.gnu.org; Mon, 03 Jun 2019 15:15:59 -0400 Received: (qmail 64064 invoked by uid 3782); 3 Jun 2019 19:15:51 -0000 Received: from acm.muc.de (p4FE15E26.dip0.t-ipconnect.de [79.225.94.38]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 03 Jun 2019 21:15:49 +0200 Received: (qmail 4440 invoked by uid 1000); 3 Jun 2019 19:15:49 -0000 Date: Mon, 3 Jun 2019 19:15:49 +0000 Message-ID: <20190603191549.GA4009@ACM> References: <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190527143109.GA5863@ACM> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Eli. To recap, the problem we were talking about was the modification-hooks overlay property, whose value is a function which gets called before and after modification of the text under an overlay. When such a function gets called, inhibit-modification-hooks is left at nil. When the other four similar overlay/text-property "change functions" get called, inhibit-modification-hooks gets bound to t. This is difficult to document coherently. My proposal of last week was to fix the code, also to bin inhibit-modification-hooks to t for the modification-hooks overlay property, even though this would be an incompatibility in Lisp. Ping? ----------------------------->----------------------------------- | On Mon, May 27, 2019 at 14:31:09 +0000, Alan Mackenzie wrote: | > Hello, Noam. | | > On Sat, May 25, 2019 at 10:36:55 -0400, Noam Postavsky wrote: | > > Alan Mackenzie writes: | | > > >>> @@ -3621,9 +3621,14 @@ Special Properties | | > > >>> +When Emacs calls these functions, @code{inhibit-modification-hooks} is > > >>> +set to @code{nil}. | v > > >> As Phillip mentioned in the OP, Emacs in fact binds it to t. | | > > > Are you sure? We're talking here about the text property (in which I > > > think inhibit-modification-hooks IS at nil) as opposed to the overlay > > > property (where inhibit-modification-hooks is bound to t). | | > > Oh, you're quite right. Here's some test code: | | > [ .... ] | | | > > Which produces this: | | > > mod-hook-text-prop (1 4), inhibit? nil | > > mod-hook-change-fun (1 4), inhibit? t | > > mod-hook-ov-prop (# nil 1 4), inhibit? t > > mod-hook-change-fun (1 1 3), inhibit? t | > > mod-hook-ov-prop (# t 1 1 3), inhibit? t > > mod-hook-change-fun (1 1), inhibit? t | > > mod-hook-change-fun (1 4 0), inhibit? t | | > > I think we need to emphasize the difference in this case, it's rather > > confusing. | V > Alternatively, we could perhaps regard the first of these results (for > modification-hooks) as a bug in the code, which seems like it ought to be > binding inhibit-modification-hooks to non-nil like the others. Maybe we > should amend the code, even though this would be a jarring > incompatibility with previous Emacs versions. Eli? > [ .... ] > > I've updated the patch based on your and Eli's feedback. > Yes, I agree that "confusing the internal mechanism" is unhelpful here. > Thanks for getting rid of it. > [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: npostavs@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Jun 2019 19:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 25111@debbugs.gnu.org, Eli Zaretskii , Noam Postavsky , Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.155959000730605 (code B ref 25111); Mon, 03 Jun 2019 19:27:02 +0000 Received: (at 25111) by debbugs.gnu.org; 3 Jun 2019 19:26:47 +0000 Received: from localhost ([127.0.0.1]:43175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXsbW-0007xX-Rg for submit@debbugs.gnu.org; Mon, 03 Jun 2019 15:26:47 -0400 Received: from mail-it1-f170.google.com ([209.85.166.170]:34534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXsbV-0007xI-4m for 25111@debbugs.gnu.org; Mon, 03 Jun 2019 15:26:45 -0400 Received: by mail-it1-f170.google.com with SMTP id u124so707614itc.1 for <25111@debbugs.gnu.org>; Mon, 03 Jun 2019 12:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=qi627i8ovoBvilSqST2uLJAkswhKkTphlEIaXGtRhOQ=; b=bIKg29KbHC8f1JPvGAKiQsMmvGqJeEuwQqTsJDkt5lz7CKiRNHngdd7bnPIdtiphoU NZg45H3yG/pDfjTjZR+t3pgXwGEYqUnC+LEwhPIzFag0uicm/eepFVQC5P8TFo2Z2tX4 ABUAmOl2ercURRkPSFlhauRD6yviEfkOv+g6Pdgq+N1sv9ZpZojAvFd+SmwgFr/bRoGD SYHp6tEg0WRRaKQj3pKMwrLJpgyLDp1O1w6gznVZt0d2u4wX5gBTZYXemAup9xwfbDjL 9PIE1I7UEQ36tce36KvNagi0klQgpbTciZVOs6rOlh+9IahEO4g28abT2IQuDXXdeoou f93g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=qi627i8ovoBvilSqST2uLJAkswhKkTphlEIaXGtRhOQ=; b=scthhS7Hcqxrj7wrH8Cz/q5x6h+zAke84HH2+fhLq0cOwu0nrwg6Bhk3qUcRsDXu0k HQO94ZyNrH27BGMZ7/naNMQZCyTIi0n9abbEmuOn2hPV5GG3BaEqsf8EhfBdT8NysvTX VFy+Su/44YHMQDbrkV3d+ijmUpDwmj3pxEQ3B6KNBimInvTzVZvc0E7ZFXcdIzEz0G1C Z30+cMKXDe9exFS9fv27Mvfv2wlIDvNbTEwmfa4pVuUftAIPkvjMCZnCEcvRLTsBokzs 7v1H7TfQoHiVvOHQj6ruoKc6QcawB4McYb0La0fEWZWogl+ktwIkN2ofyvryWciWILaO cS5Q== X-Gm-Message-State: APjAAAU8vLfARD7qqULpKzo8L8DTeCZkuQ1Y2mtcy6hlIxU/bKRYRkXj vtmyNoMGmYtj3embZEBgNmoE4oKa X-Google-Smtp-Source: APXvYqxiZ4mlssbTGY/QKRQ4AO9vAcYhdoeLT9EzR5u3biZ9QXfMLUsMH2W1lDChR4OwdT1JuKbYHQ== X-Received: by 2002:a02:bb83:: with SMTP id g3mr18497289jan.139.1559589999170; Mon, 03 Jun 2019 12:26:39 -0700 (PDT) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.51.196]) by smtp.gmail.com with ESMTPSA id n21sm4391322ioh.30.2019.06.03.12.26.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Jun 2019 12:26:38 -0700 (PDT) From: npostavs@gmail.com References: <83eg1iiffm.fsf@gnu.org> <87pol1kon4.fsf@russet.org.uk> <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> Date: Mon, 03 Jun 2019 15:26:38 -0400 In-Reply-To: <20190603191549.GA4009@ACM> (Alan Mackenzie's message of "Mon, 3 Jun 2019 19:15:49 +0000") Message-ID: <85tvd6bhch.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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.0 (-) Alan Mackenzie writes: > Hello, Eli. > > To recap, the problem we were talking about was the modification-hooks > overlay property, whose value is a function which gets called before and > after modification of the text under an overlay. > > When such a function gets called, inhibit-modification-hooks is left at > nil. When the other four similar overlay/text-property "change > functions" get called, inhibit-modification-hooks gets bound to t. Minor correction: it's the modification-hooks text property which have inhibit-modification-hooks left at nil, when the overlay property modification-hooks get called inhibit-modification-hooks is bound to t, just like in the after/before-change-functions case. > This is difficult to document coherently. And confusing, as evidenced by the fact that we both got confused about it in this very thread :) > My proposal of last week was to fix the code, also to bin > inhibit-modification-hooks to t for the modification-hooks overlay > property, even though this would be an incompatibility in Lisp. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jun 2019 09:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@gmail.com Cc: Eli Zaretskii , 25111@debbugs.gnu.org, Phillip Lord Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.15596407687679 (code B ref 25111); Tue, 04 Jun 2019 09:33:01 +0000 Received: (at 25111) by debbugs.gnu.org; 4 Jun 2019 09:32:48 +0000 Received: from localhost ([127.0.0.1]:43890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hY5oF-0001zm-NC for submit@debbugs.gnu.org; Tue, 04 Jun 2019 05:32:47 -0400 Received: from colin.muc.de ([193.149.48.1]:37649 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hY5oD-0001zd-B0 for 25111@debbugs.gnu.org; Tue, 04 Jun 2019 05:32:46 -0400 Received: (qmail 33510 invoked by uid 3782); 4 Jun 2019 09:32:43 -0000 Received: from acm.muc.de (p4FE15D2B.dip0.t-ipconnect.de [79.225.93.43]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 04 Jun 2019 11:32:41 +0200 Received: (qmail 6089 invoked by uid 1000); 4 Jun 2019 09:32:41 -0000 Date: Tue, 4 Jun 2019 09:32:41 +0000 Message-ID: <20190604093241.GA5790@ACM> References: <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85tvd6bhch.fsf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Noam. On Mon, Jun 03, 2019 at 15:26:38 -0400, npostavs@gmail.com wrote: > Alan Mackenzie writes: > > Hello, Eli. > > To recap, the problem we were talking about was the modification-hooks > > overlay property, whose value is a function which gets called before and > > after modification of the text under an overlay. > > When such a function gets called, inhibit-modification-hooks is left at > > nil. When the other four similar overlay/text-property "change > > functions" get called, inhibit-modification-hooks gets bound to t. > Minor correction: it's the modification-hooks text property which have > inhibit-modification-hooks left at nil, when the overlay property > modification-hooks get called inhibit-modification-hooks is bound to t, > just like in the after/before-change-functions case. Oh, bother. ;-) > > This is difficult to document coherently. > And confusing, as evidenced by the fact that we both got confused about > it in this very thread :) > > My proposal of last week was to fix the code, also to bind > > inhibit-modification-hooks to t for the modification-hooks overlay > > property, even though this would be an incompatibility in Lisp. How about this? diff --git a/src/textprop.c b/src/textprop.c index ae42c44185..607bd40676 100644 --- a/src/textprop.c +++ b/src/textprop.c @@ -2247,6 +2247,8 @@ verify_interval_modification (struct buffer *buf, if (!inhibit_modification_hooks) { + int count = SPECPDL_INDEX (); + specbind (Qinhibit_modification_hooks, Qt); hooks = Fnreverse (hooks); while (! NILP (hooks)) { @@ -2254,6 +2256,7 @@ verify_interval_modification (struct buffer *buf, make_fixnum (end)); hooks = Fcdr (hooks); } + unbind_to (count, Qnil); } } } -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jun 2019 14:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 25111@debbugs.gnu.org, npostavs@gmail.com, phillip.lord@russet.org.uk Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.15596589936899 (code B ref 25111); Tue, 04 Jun 2019 14:37:02 +0000 Received: (at 25111) by debbugs.gnu.org; 4 Jun 2019 14:36:33 +0000 Received: from localhost ([127.0.0.1]:45553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYAY8-0001n8-W7 for submit@debbugs.gnu.org; Tue, 04 Jun 2019 10:36:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYAY6-0001mw-IF for 25111@debbugs.gnu.org; Tue, 04 Jun 2019 10:36:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYAY0-0001tT-JF; Tue, 04 Jun 2019 10:36:20 -0400 Received: from [176.228.60.248] (port=2912 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hYAXz-0000jQ-Le; Tue, 04 Jun 2019 10:36:20 -0400 Date: Tue, 04 Jun 2019 17:36:12 +0300 Message-Id: <838suhto2r.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190604093241.GA5790@ACM> (message from Alan Mackenzie on Tue, 4 Jun 2019 09:32:41 +0000) References: <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> <20190604093241.GA5790@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Tue, 4 Jun 2019 09:32:41 +0000 > Cc: Eli Zaretskii , Phillip Lord , > 25111@debbugs.gnu.org > From: Alan Mackenzie > > > > This is difficult to document coherently. > > > And confusing, as evidenced by the fact that we both got confused about > > it in this very thread :) > > > > My proposal of last week was to fix the code, also to bind > > > inhibit-modification-hooks to t for the modification-hooks overlay > > > property, even though this would be an incompatibility in Lisp. > > How about this? Please wait with this for a few days. I must refresh my memory about this old issue, and re-read the code, and I'm currently busy with more urgent issues, like the harfbuzz branch and a couple of display bugs. TIA, and sorry for being unable to respond quickly. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Jun 2019 12:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: acm@muc.de, phillip.lord@russet.org.uk Cc: 25111@debbugs.gnu.org, npostavs@gmail.com Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.156008165319714 (code B ref 25111); Sun, 09 Jun 2019 12:01:02 +0000 Received: (at 25111) by debbugs.gnu.org; 9 Jun 2019 12:00:53 +0000 Received: from localhost ([127.0.0.1]:54398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hZwVJ-00057t-Ff for submit@debbugs.gnu.org; Sun, 09 Jun 2019 08:00:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hZwVG-00057Z-0h for 25111@debbugs.gnu.org; Sun, 09 Jun 2019 08:00:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hZwV5-0007pQ-QT; Sun, 09 Jun 2019 08:00:43 -0400 Received: from [176.228.60.248] (port=1383 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hZwUp-0007y6-GV; Sun, 09 Jun 2019 08:00:33 -0400 Date: Sun, 09 Jun 2019 15:00:16 +0300 Message-Id: <83muirarzj.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <838suhto2r.fsf@gnu.org> (message from Eli Zaretskii on Tue, 04 Jun 2019 17:36:12 +0300) References: <83bmwlggix.fsf@gnu.org> <878trmxgjh.fsf@russet.org.uk> <83lgvlcet1.fsf@gnu.org> <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> <20190604093241.GA5790@ACM> <838suhto2r.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Tue, 04 Jun 2019 17:36:12 +0300 > From: Eli Zaretskii > Cc: phillip.lord@russet.org.uk, 25111@debbugs.gnu.org, npostavs@gmail.com > > > Date: Tue, 4 Jun 2019 09:32:41 +0000 > > Cc: Eli Zaretskii , Phillip Lord , > > 25111@debbugs.gnu.org > > From: Alan Mackenzie > > > > > > This is difficult to document coherently. > > > > > And confusing, as evidenced by the fact that we both got confused about > > > it in this very thread :) > > > > > > My proposal of last week was to fix the code, also to bind > > > > inhibit-modification-hooks to t for the modification-hooks overlay > > > > property, even though this would be an incompatibility in Lisp. > > > > How about this? > > Please wait with this for a few days. OK, after re-reading the discussions and the code, I don't think we should make the incompatible change suggested by Alan. We haven't bound inhibit-modification-hooks to t in the text-property hooks since the day the code was written, 24 years ago, so it makes no sense to me to do that now. Let's document the exception and move on. Noam's last patch LGTM, with the single minor gotcha: > +When Emacs calls these functions, @code{inhibit-modification-hooks} is > +set to @code{nil}, unlike for change hooks. This is from the part that changes the "Special Properties" node, and it's inaccurate: we don't bind inhibit-modification-hooks to nil, we just leave it at its previous binding. This distinction is important in recursive calls, when the caller caused inhibit-modification-hooks to be bound to non-nil. Another minor comment, although not to the proposed text, is that the fact that inhibit-modification-hooks is bound to t when the hook specified by the overlay properties are called is because those hooks are called from within signal_before_change and signal_after_change, which perform these bindings, and the bindings stay in effect both for before/after-change-functions and for hooks specified by overlay properties. By contrast, the hooks specified by text properties are called before that binding becomes in effect (which is why we need a separate check whether inhibit_modification_hooks are non-nil inside verify_interval_modification, which calls the text-property hooks). Thanks. From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Jun 2019 20:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: npostavs@gmail.com, 25111@debbugs.gnu.org, phillip.lord@russet.org.uk Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.156011313712501 (code B ref 25111); Sun, 09 Jun 2019 20:46:02 +0000 Received: (at 25111) by debbugs.gnu.org; 9 Jun 2019 20:45:37 +0000 Received: from localhost ([127.0.0.1]:55473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ha4h6-0003FY-TG for submit@debbugs.gnu.org; Sun, 09 Jun 2019 16:45:37 -0400 Received: from colin.muc.de ([193.149.48.1]:33900 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ha4h2-0003FN-50 for 25111@debbugs.gnu.org; Sun, 09 Jun 2019 16:45:33 -0400 Received: (qmail 96889 invoked by uid 3782); 9 Jun 2019 20:45:27 -0000 Received: from acm.muc.de (p2E5D56FA.dip0.t-ipconnect.de [46.93.86.250]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 09 Jun 2019 22:45:25 +0200 Received: (qmail 18569 invoked by uid 1000); 9 Jun 2019 20:45:25 -0000 Date: Sun, 9 Jun 2019 20:45:25 +0000 Message-ID: <20190609204525.GB6712@ACM> References: <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> <20190604093241.GA5790@ACM> <838suhto2r.fsf@gnu.org> <83muirarzj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83muirarzj.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Eli. On Sun, Jun 09, 2019 at 15:00:16 +0300, Eli Zaretskii wrote: > > Date: Tue, 04 Jun 2019 17:36:12 +0300 > > From: Eli Zaretskii > > Cc: phillip.lord@russet.org.uk, 25111@debbugs.gnu.org, npostavs@gmail.com > > > Date: Tue, 4 Jun 2019 09:32:41 +0000 > > > Cc: Eli Zaretskii , Phillip Lord , > > > 25111@debbugs.gnu.org > > > From: Alan Mackenzie > > > > > This is difficult to document coherently. > > > > And confusing, as evidenced by the fact that we both got confused about > > > > it in this very thread :) > > > > > My proposal of last week was to fix the code, also to bind > > > > > inhibit-modification-hooks to t for the modification-hooks overlay > > > > > property, even though this would be an incompatibility in Lisp. > > > How about this? > > Please wait with this for a few days. > OK, after re-reading the discussions and the code, I don't think we > should make the incompatible change suggested by Alan. We haven't > bound inhibit-modification-hooks to t in the text-property hooks since > the day the code was written, 24 years ago, so it makes no sense to me > to do that now. Let's document the exception and move on. Thanks for looking at this and taking the decision. > Noam's last patch LGTM, with the single minor gotcha: > > +When Emacs calls these functions, @code{inhibit-modification-hooks} is > > +set to @code{nil}, unlike for change hooks. > This is from the part that changes the "Special Properties" node, and > it's inaccurate: we don't bind inhibit-modification-hooks to nil, we > just leave it at its previous binding. This distinction is important > in recursive calls, when the caller caused inhibit-modification-hooks > to be bound to non-nil. Yes. The "is set" formulation is ambiguous. It could mean "gets set (bound)", which is how you read it; it could also mean "happens to be set to (at the time)", which was how I intended it. Ambiguous writing isn't good, so I suggest: "When Emacs calls this function, @code{inhibit-modification-hooks} is left at its current value; unlike for change hooks, it does not get bound to non-@code{nil}. > Another minor comment, although not to the proposed text, is that the > fact that inhibit-modification-hooks is bound to t when the hook > specified by the overlay properties are called is because those hooks > are called from within signal_before_change and signal_after_change, > which perform these bindings, and the bindings stay in effect both for > before/after-change-functions and for hooks specified by overlay > properties. By contrast, the hooks specified by text properties are > called before that binding becomes in effect (which is why we need a > separate check whether inhibit_modification_hooks are non-nil inside > verify_interval_modification, which calls the text-property hooks). Thanks, that's helpful. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jun 2019 12:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , npostavs@gmail.com Cc: 25111@debbugs.gnu.org, phillip.lord@russet.org.uk Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.156138078325780 (code B ref 25111); Mon, 24 Jun 2019 12:54:01 +0000 Received: (at 25111) by debbugs.gnu.org; 24 Jun 2019 12:53:03 +0000 Received: from localhost ([127.0.0.1]:55780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hfOT0-0006hk-MH for submit@debbugs.gnu.org; Mon, 24 Jun 2019 08:53:02 -0400 Received: from colin.muc.de ([193.149.48.1]:30074 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hfOSy-0006hJ-Fu for 25111@debbugs.gnu.org; Mon, 24 Jun 2019 08:53:01 -0400 Received: (qmail 56003 invoked by uid 3782); 24 Jun 2019 12:52:50 -0000 Received: from acm.muc.de (p4FE15E6F.dip0.t-ipconnect.de [79.225.94.111]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 24 Jun 2019 14:52:49 +0200 Received: (qmail 4176 invoked by uid 1000); 24 Jun 2019 12:52:49 -0000 Date: Mon, 24 Jun 2019 12:52:49 +0000 Message-ID: <20190624125249.GB4781@ACM> References: <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> <20190604093241.GA5790@ACM> <838suhto2r.fsf@gnu.org> <83muirarzj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83muirarzj.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) 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.0 (-) Hello, Eli and Noam (but mainly Noam). It's about time we finally got this matter tidied up, so... On Sun, Jun 09, 2019 at 15:00:16 +0300, Eli Zaretskii wrote: > OK, after re-reading the discussions and the code, I don't think we > should make the incompatible change suggested by Alan. We haven't > bound inhibit-modification-hooks to t in the text-property hooks since > the day the code was written, 24 years ago, so it makes no sense to me > to do that now. Let's document the exception and move on. > Noam's last patch LGTM, with the single minor gotcha: > > +When Emacs calls these functions, @code{inhibit-modification-hooks} is > > +set to @code{nil}, unlike for change hooks. > This is from the part that changes the "Special Properties" node, and > it's inaccurate: we don't bind inhibit-modification-hooks to nil, we > just leave it at its previous binding. This distinction is important > in recursive calls, when the caller caused inhibit-modification-hooks > to be bound to non-nil. I've corrected this bit by saying that "Unlike with other similar hooks, when Emacs calls these functions, `inhibit-modification-hooks' does _not_ get bound to non-`nil'". I've also added bits to the descriptions of insert-{in-front,behind}-hooks, the text property version of them, documenting that inhibit-modification-hooks gets bound to non-nil. [ .... ] I think the changes as now formulated are right. Perhaps one or both of you might like to give the following patch a quick review. Thanks! diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index 7e8abb0440..68f40b55d8 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -1752,9 +1752,12 @@ Overlay Properties length is the number of characters deleted, and the post-change beginning and end are equal.) -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +When these functions are called, @code{inhibit-modification-hooks} is +bound to non-@code{nil}. If the functions modify the buffer, you +might want to bind @code{inhibit-modification-hooks} to nil, so as to +cause the change hooks to run for these modifications. However, doing +this may call your own change hook recursively, so be sure to prepare +for that. @xref{Change Hooks}. Text properties also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Special Properties}). diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi index 2e7c497f57..95ed758914 100644 --- a/doc/lispref/text.texi +++ b/doc/lispref/text.texi @@ -3621,9 +3621,12 @@ Special Properties hook will only be run when removing some characters, replacing them with others, or changing their text-properties. -If these functions modify the buffer, they should bind -@code{inhibit-modification-hooks} to @code{t} around doing so, to -avoid confusing the internal mechanism that calls these hooks. +Unlike with other similar hooks, when Emacs calls these functions, +@code{inhibit-modification-hooks} does @emph{not} get bound to +non-@code{nil}. If the functions modify the buffer, you should +consider binding this variable to non-@code{nil} to prevent any buffer +changes running the change hooks. Otherwise, you must be prepared for +recursive calls. @xref{Change Hooks}. Overlays also support the @code{modification-hooks} property, but the details are somewhat different (@pxref{Overlay Properties}). @@ -3639,6 +3642,13 @@ Special Properties beginning and end of the inserted text. The functions are called @emph{after} the actual insertion takes place. +When these functions are called, @code{inhibit-modification-hooks} is +bound to non-@code{nil}. If the functions modify the buffer, you +might want to bind @code{inhibit-modification-hooks} to nil, so as to +cause the change hooks to run for these modifications. However, doing +this may call your own change hook recursively, so be sure to prepare +for that. + See also @ref{Change Hooks}, for other hooks that are called when you change text in a buffer. @@ -5650,5 +5660,8 @@ Change Hooks a modification hook does not cause other modification hooks to be run. If you do want modification hooks to be run in a particular piece of code that is itself run from a modification hook, then rebind locally -@code{inhibit-modification-hooks} to @code{nil}. +@code{inhibit-modification-hooks} to @code{nil}. However, doing this +may cause recursive calls to the modification hooks, so be sure to +prepare for that (for example, by binding some variable which tells +your hook to do nothing). @end defvar -- Alan Mackenzie (Nuremberg, Germany). From unknown Tue Aug 19 13:27:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jun 2019 22:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , 25111@debbugs.gnu.org, phillip.lord@russet.org.uk Received: via spool by 25111-submit@debbugs.gnu.org id=B25111.15614165033557 (code B ref 25111); Mon, 24 Jun 2019 22:49:02 +0000 Received: (at 25111) by debbugs.gnu.org; 24 Jun 2019 22:48:23 +0000 Received: from localhost ([127.0.0.1]:58257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hfXl9-0000vH-0f for submit@debbugs.gnu.org; Mon, 24 Jun 2019 18:48:23 -0400 Received: from mail-io1-f51.google.com ([209.85.166.51]:37775) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hfXl7-0000v0-Nc for 25111@debbugs.gnu.org; Mon, 24 Jun 2019 18:48:22 -0400 Received: by mail-io1-f51.google.com with SMTP id e5so731702iok.4 for <25111@debbugs.gnu.org>; Mon, 24 Jun 2019 15:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=pxEamgLbrgseuwE2BjiEuwov1duVqcyvzot8thoB4es=; b=bv+33wuaONVD9xRHkV3RhoLD0pH/yt7PB2MAg9/cESj3hgZ6fcKqTZDaCtef/V4bUH pUkZQPn2N5PAb43ysujmg1xDBcAenVa3MmfdUw06uHH+FNpi+DZJt7ZDtkZ/sZDhf5vq BQiGoejDwMbvN9NtzuDM9Mxw8BHzc3XWCrLsw+eQdOXetr82DfmkC0RycWw/lCLrRmbf PWsfBdevWABq365Ice1YicvdSR/kTl0BVWLGmNU+86lZWWyiQ5wBAyOJshwUDhYgcYPH zQyrrt7fweoLK04ZPHwz/Hkwma7YIjxMH/mcuOEGduXs8wspmtxji7ZsG3Lx3BFzxr6Z f/+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=pxEamgLbrgseuwE2BjiEuwov1duVqcyvzot8thoB4es=; b=Qi9chR6ZtVNQuz5FT5+D3q8lScutwZZfczfYo1Lp53lNYd1075BxUkxCljiY9pOY/U KM1v7aXjajkXsGqS4cUSYNKVIe8xhicBmunnR3cEV4qh/YOCvecb9wmkM6OEeFQX9HRn FiZKN7DViqXMus3GbJuKIJ+w7TGxWB4D2LGXelDmh26QDunJJMvsJwfsWC2iuBNDaat1 4H5sAHmTkRpJ+WgZR5XAFlvB2nbfjao/gursu8b29anCaGE5bJkbHZaGovIVig9E8flS 9HuVE0oKD0ZWF3cfMj4lZRvO18w3JTKcaKTjp3NpZvBwWBXFEgJmQiDxru3L9F65G2i7 SrPw== X-Gm-Message-State: APjAAAXqAQmR8TuiYcxjzql6c+VBilpdGEREpLR77sVfH+kHK3OCPgcp eUJLkotn9DUiOoy09twcBMc= X-Google-Smtp-Source: APXvYqxkS31QrzpdaigdFXAl6ybZOQhUcbTHQfz4kSK81vmtrFh55r7FGdR3lsq7A3E01MaBNSTaMA== X-Received: by 2002:a5d:9251:: with SMTP id e17mr16461787iol.21.1561416495858; Mon, 24 Jun 2019 15:48:15 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id f17sm27706465ioc.2.2019.06.24.15.48.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Jun 2019 15:48:15 -0700 (PDT) From: Noam Postavsky References: <20190519203119.GA5309@ACM> <87y32u908k.fsf@gmail.com> <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> <20190604093241.GA5790@ACM> <838suhto2r.fsf@gnu.org> <83muirarzj.fsf@gnu.org> <20190624125249.GB4781@ACM> Date: Mon, 24 Jun 2019 18:48:14 -0400 In-Reply-To: <20190624125249.GB4781@ACM> (Alan Mackenzie's message of "Mon, 24 Jun 2019 12:52:49 +0000") Message-ID: <8736jytxap.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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.0 (-) Alan Mackenzie writes: > Hello, Eli and Noam (but mainly Noam). > > It's about time we finally got this matter tidied up, so... Yeah, sorry I dropped the ball on this. > I think the changes as now formulated are right. Perhaps one or both of > you might like to give the following patch a quick review. Thanks! Minor formatting nitpick: > +++ b/doc/lispref/display.texi > @@ -1752,9 +1752,12 @@ Overlay Properties > +When these functions are called, @code{inhibit-modification-hooks} is > +bound to non-@code{nil}. If the functions modify the buffer, you > +might want to bind @code{inhibit-modification-hooks} to nil, so as to ^^^ > +cause the change hooks to run for these modifications. However, doing > +this may call your own change hook recursively, so be sure to prepare > +for that. @xref{Change Hooks}. > +++ b/doc/lispref/text.texi > @@ -3639,6 +3642,13 @@ Special Properties > beginning and end of the inserted text. The functions are called > @emph{after} the actual insertion takes place. > > +When these functions are called, @code{inhibit-modification-hooks} is > +bound to non-@code{nil}. If the functions modify the buffer, you > +might want to bind @code{inhibit-modification-hooks} to nil, so as to ^^^ @code{nil} for both of these, right? Otherwise looks good to me. From unknown Tue Aug 19 13:27:26 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: "Phillip Lord" Subject: bug#25111: closed (Re: bug#25111: (Inaccurate documentation of inhibit-modification-hooks)) Message-ID: References: <20190625091709.GA5471@ACM> X-Gnu-PR-Message: they-closed 25111 X-Gnu-PR-Package: emacs Reply-To: 25111@debbugs.gnu.org Date: Tue, 25 Jun 2019 09:18:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1561454283-17146-1" This is a multi-part message in MIME format... ------------=_1561454283-17146-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #25111: How modification-hooks let-bind inhibit-modification-hooks? which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 25111@debbugs.gnu.org. --=20 25111: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25111 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1561454283-17146-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 25111-done) by debbugs.gnu.org; 25 Jun 2019 09:17:17 +0000 Received: from localhost ([127.0.0.1]:58633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hfhZl-0004Rc-8i for submit@debbugs.gnu.org; Tue, 25 Jun 2019 05:17:17 -0400 Received: from colin.muc.de ([193.149.48.1]:61220 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hfhZj-0004RS-3d for 25111-done@debbugs.gnu.org; Tue, 25 Jun 2019 05:17:15 -0400 Received: (qmail 13062 invoked by uid 3782); 25 Jun 2019 09:17:12 -0000 Received: from acm.muc.de (p4FE15DD6.dip0.t-ipconnect.de [79.225.93.214]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 25 Jun 2019 11:17:09 +0200 Received: (qmail 5478 invoked by uid 1000); 25 Jun 2019 09:17:09 -0000 Date: Tue, 25 Jun 2019 09:17:09 +0000 To: Noam Postavsky Subject: Re: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) Message-ID: <20190625091709.GA5471@ACM> References: <20190525134407.GA10864@ACM> <87sgt28ut4.fsf@gmail.com> <20190527143109.GA5863@ACM> <20190603191549.GA4009@ACM> <85tvd6bhch.fsf@gmail.com> <20190604093241.GA5790@ACM> <838suhto2r.fsf@gnu.org> <83muirarzj.fsf@gnu.org> <20190624125249.GB4781@ACM> <8736jytxap.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8736jytxap.fsf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25111-done Cc: Eli Zaretskii , phillip.lord@russet.org.uk, 25111-done@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.0 (-) Hello, Noam. On Mon, Jun 24, 2019 at 18:48:14 -0400, Noam Postavsky wrote: > Alan Mackenzie writes: [ .... ] > > I think the changes as now formulated are right. Perhaps one or > > both of you might like to give the following patch a quick review. > > Thanks! > Minor formatting nitpick: > > +++ b/doc/lispref/display.texi > > @@ -1752,9 +1752,12 @@ Overlay Properties > > +When these functions are called, @code{inhibit-modification-hooks} is > > +bound to non-@code{nil}. If the functions modify the buffer, you > > +might want to bind @code{inhibit-modification-hooks} to nil, so as to > ^^^ > > +cause the change hooks to run for these modifications. However, doing > > +this may call your own change hook recursively, so be sure to prepare > > +for that. @xref{Change Hooks}. > > +++ b/doc/lispref/text.texi > > @@ -3639,6 +3642,13 @@ Special Properties > > beginning and end of the inserted text. The functions are called > > @emph{after} the actual insertion takes place. > > +When these functions are called, @code{inhibit-modification-hooks} is > > +bound to non-@code{nil}. If the functions modify the buffer, you > > +might want to bind @code{inhibit-modification-hooks} to nil, so as to > ^^^ > @code{nil} for both of these, right? Otherwise looks good to me. Whoops! Thanks for spotting these. I've fixed them and committed the changes. I'm closing the bug with this post. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1561454283-17146-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 4 Dec 2016 20:54:23 +0000 Received: from localhost ([127.0.0.1]:56192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDdnj-0000Y0-4G for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:23 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41377) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDdnh-0000Xn-JB for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDdnb-0007vR-Ku for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:16 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:53216) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cDdnb-0007vN-HX for submit@debbugs.gnu.org; Sun, 04 Dec 2016 15:54:15 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDdna-0002K5-DB for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 15:54:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDdnV-0007um-JX for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 15:54:14 -0500 Received: from mailgw.mycpanelcloud.co.uk ([185.116.214.213]:28432) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cDdnV-0007rm-8w for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 15:54:09 -0500 Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id B74AAC46B6 for ; Sun, 4 Dec 2016 21:53:09 +0000 (GMT) X-Virus-Scanned: by SpamTitan at mycpanelcloud.co.uk Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id DFDBFC445E for ; Sun, 4 Dec 2016 21:53:08 +0000 (GMT) Received: from cloud103.planethippo.com (cloud103.planethippo.com [31.216.48.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTPS id D6596C4417 for ; Sun, 4 Dec 2016 21:53:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:To:From:Subject:Date:Message-ID:Sender:Reply-To:Cc: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=qF/y+idlm+cA64TRgxGyU2RRuSl/3Q+xNMmbxJJ7kXA=; b=ZsXxa5W9AG6d0m+Svj2EMnRzY3 G0hYkWb+qncT9kGHwm/ZsOxrC3CFS5E3VUMwT2i622mRuARK6lLsBe2/UGOJwXfeTYUG1n8zxY0QQ E4+88JZ2G3lcEzkSdqhT8PYuknXHS21B1i+6wVRlXFIxO6ahafdRszi6exVs+MyKfjwYguTSKYfG8 nkGIEODIPcPiOisBkI80QFyXg1QIzE8iQGIv2BI0Cc53xQjLjZC2vkV6KO0mYN8eIGUiht9JZyqWt aLaANqe2NWD1KXsGQXvolsZ3uWwK9Ro+yzN8l2Z2hbjAvXen8V7rYxYUzUoMoB3+XMKlrDFsYgcqr ku/5bBZg==; Received: from [127.0.0.1] (port=49121 helo=cloud103.planethippo.com) by cloud103.planethippo.com with esmtpa (Exim 4.87) (envelope-from ) id 1cDdmm-0022HK-PH for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2016 20:53:24 +0000 Received: from 77.103.60.43 ([77.103.60.43]) (SquirrelMail authenticated user phillip.lord@russet.org.uk) by cloud103.planethippo.com with HTTP; Sun, 4 Dec 2016 20:53:24 -0000 Message-ID: Date: Sun, 4 Dec 2016 20:53:24 -0000 Subject: From: "Phillip Lord" To: bug-gnu-emacs@gnu.org User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.0 (---) 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: -3.0 (---) The documentation for "modification-hooks" on overlays says: If these functions modify the buffer, they should bind =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80=98t=E2=80=99 = around doing so, to avoid confusing the internal mechanism that calls these hooks. But as far as I can see, the only place these gets called "signal_after_change" and "signal_before_change", inhibit-modification-hooks is already specbou= nd to t, so this advice is unnecessary. Also, the documentation for inhibit-modification-hooks says: If you do want modification hooks to be run in a particular piece of code that is itself run from a modification hook, then rebind locally =E2=80=98inhibit-modification-hooks=E2=80=99 to =E2=80= =98nil=E2=80=99. which suggests that, in fact, it is possible to call the modification hooks from inside another call to these functions. This is true for both emacs-25 and master. ------------=_1561454283-17146-1--