From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#51766: 29.0.50; Return value of buffer-chars-modified-tick changes when buffer text is not yet changed before inserting a character for non-latin input methods Date: Thu, 16 Jun 2022 22:54:22 -0400 Message-ID: References: <87mtmalrs1.fsf@localhost> <837dde200c.fsf@gnu.org> <87k0helmig.fsf@localhost> <831r3m1tpk.fsf@gnu.org> <8735o1r31q.fsf@localhost> <834k8hzi10.fsf@gnu.org> <87zgq9pmb6.fsf@localhost> <831r3lzfk4.fsf@gnu.org> <87wnldpk5x.fsf@localhost> <83zgq9xv1y.fsf@gnu.org> <87r1bkpgjw.fsf@localhost> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3027"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , 51766@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 17 04:55:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o228h-0000bb-B4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Jun 2022 04:55:15 +0200 Original-Received: from localhost ([::1]:45202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o228f-0007KN-Vw for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Jun 2022 22:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o228T-0007HE-VL for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2022 22:55:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49573) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o228T-0002xA-M9 for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2022 22:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o228T-0006Y7-KH for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2022 22:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Jun 2022 02:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51766 X-GNU-PR-Package: emacs Original-Received: via spool by 51766-submit@debbugs.gnu.org id=B51766.165543447725140 (code B ref 51766); Fri, 17 Jun 2022 02:55:01 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 17 Jun 2022 02:54:37 +0000 Original-Received: from localhost ([127.0.0.1]:43470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o2284-0006XP-Op for submit@debbugs.gnu.org; Thu, 16 Jun 2022 22:54:36 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o227z-0006X9-7t for 51766@debbugs.gnu.org; Thu, 16 Jun 2022 22:54:35 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BADF18073F; Thu, 16 Jun 2022 22:54:25 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 20A8380009; Thu, 16 Jun 2022 22:54:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1655434464; bh=rqzqpksyF2942+9RDxYhpNCo4iPWZnpGG+lxVPWxNbs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=m6jCLslpABE/dTX3ir2bvJCXuH5c1/l6obEfPjiIXaDlCqHOWJpU8rk6C32GswVy1 LYLjqY6dyfocRNKdmUfVLa5AIsFW/IAY893xeBg1LKMDwZNw0YquWyoMYz5dcjDe2o H8TUC/JUsxHsGXOQRuatpBgWG/QlMOlwCdKMAaQ0OTJdzUjlxQNzUG9kKCK4hRh7lh RTJUyBvXwbrtOHBO6Vl8c+oBTowsJ6SA9Dfsqj8RrX//T3h7iRLJmn9fU+g60gF8Jy Jwo22s56i4ojgj21ghNn7VRGJ5qpmsiC57wG6UBtYaQm4kJQ02qogYcP1N7A8MAAZI n2Daz26A/u4ww== Original-Received: from alfajor (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B985E120163; Thu, 16 Jun 2022 22:54:23 -0400 (EDT) In-Reply-To: <87r1bkpgjw.fsf@localhost> (Ihor Radchenko's message of "Sat, 13 Nov 2021 17:10:11 +0800") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:234666 Archived-At: > (let ((inhibit-modification-hooks t)) > (insert "Insertion that will never trigger before/after-change-functions")) This is a severely broken piece of code. I don't think anyone should try and handle this in any other way than by screaming bloody murder when it detects the consequences. > (defun org-element--after-change-function (...) > (setq org-element-chars-modified-tick (buffer-chars-modified-tick)) > (org-element-cache-submit-request ...)) > > (defun org-element--before-change-function (...) > (unless (eq org-element-chars-modified-tick (buffer-chars-modified-tick)) > ;; Buffer has been changed without calling after-change-function > ;; and we have no way to determine which part of buffer has been changed. > )) So this `unless` is intended to detect the case where we should scream bloody murder, right? Why do you need it? AFAICT it should only be needed for debugging purposes until the offender is found and shamed publicly. [ I have a weird feeling that I might be one of the offenders. ] > Ideally, a way to track _all_ buffer modifications regardless of > inhibit-modification-hooks would be useful. I don't think this *can* exist: if we add a mechanism which ignores `inhibit-modification-hooks` it will still need some way to ignore some changes so we'll need another `inhibit-` variable to "silence" those changes and we'll be back at square one. I think the better way to proceed is to figure out why/when significant changes are made while `inhibit-modification-hooks` is non-nil, since that's the origin of your problems, AFAICT. Stefan