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: Fri, 17 Jun 2022 09:28:21 -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> <87y1xv7ggf.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="21754"; 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 15:29:24 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 1o2C2N-0005VJ-LB for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Jun 2022 15:29:23 +0200 Original-Received: from localhost ([::1]:49776 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2C2M-0002AN-7Z for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Jun 2022 09:29:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41174) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2C22-00028F-Ca for bug-gnu-emacs@gnu.org; Fri, 17 Jun 2022 09:29:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50488) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o2C22-0006oE-1I for bug-gnu-emacs@gnu.org; Fri, 17 Jun 2022 09:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o2C21-00054p-Tq for bug-gnu-emacs@gnu.org; Fri, 17 Jun 2022 09:29: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 13:29: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.165547251319477 (code B ref 51766); Fri, 17 Jun 2022 13:29:01 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 17 Jun 2022 13:28:33 +0000 Original-Received: from localhost ([127.0.0.1]:44385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o2C1Y-000542-K2 for submit@debbugs.gnu.org; Fri, 17 Jun 2022 09:28:32 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o2C1W-00053q-GI for 51766@debbugs.gnu.org; Fri, 17 Jun 2022 09:28:31 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1C4A3441268; Fri, 17 Jun 2022 09:28:25 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 590234410EA; Fri, 17 Jun 2022 09:28:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1655472503; bh=i/vDSExZcgIUpyn48B0KkvA/YVClW/bkAM2pgA/tlvM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NozX5ByO5zjOG+/1UlyKjadQBzNVyfGz2ASD5F0/Y4yB0EYZdFtVzOj1YM+6gxyQX Upqfo/cs8CiXBgbeM2k3ZzC3nSbABWmmXbl//UuGTJo9kplMh0lr/Ge1V94C0fAV73 n2x3Niq87UguDQf2UlrohhxSLD7MJtQvBDiFNAC15G6ME5EtwjlgGHPjTwTW1gFIvl d/lPF889Uh69aCPcpAjq7oP89rjQo9LLyBL1oOGcf1tNPZnSnkmulNkOcc2ZF/eExI GnnCujacgDzaQDW4/0v2OO22UPo3y7Ydd+oYQ144sjw+OTuwCTpub0WGSfhfAl23d8 VYgJF5sjczBUA== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 28D211201CF; Fri, 17 Jun 2022 09:28:23 -0400 (EDT) In-Reply-To: <87y1xv7ggf.fsf@localhost> (Ihor Radchenko's message of "Fri, 17 Jun 2022 18:05:36 +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:234690 Archived-At: > Well. This was also my assumption. I initially implemented the checking > code to detect internal errors in Org. > > Then we received 12 bug reports on this. The offenders were identified > in some cases. They were: > - polymode, valign, and ox-hugo > - Doom (unrelated to this particular issue, but Doom is let-binding major-mode...) > - Emacs quail and also replace-match in some cases (because of > false-positives caused by changing buffer-chars-modified-tick) IIUC Quail and replace-match shouldn't be in the above list: they're caught by your debugging check but they're false positives. > valign relies on disabling modification hooks because it is otherwise > difficult to figure out pixel width of a string in current buffer: > https://github.com/casouri/valign/issues/30 AFAIK this is *also* a false positive: the buffer is only temporarily modified within the `with-silent-modifications` and reverted to its previous state before the end of that macro, so there's no need to flush your parser's state. >> 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. > > See the above. There is real-world code doing things that make > Emacs ignore after-change-functions. I don't see how this relates to what I'm saying: what I'm saying is that for the same reason there's code that has very valid reasons to inhibit `after-change-functions`, there will be code that has very valid reasons to inhibit some new `after-really-every-change-functions`, and then there will inevitably also be code that abuses this. The only real solution is to "push back" and get those abuses fixed. One thing you could do, for example is replace your char-modified-tick check with one based on buffer-size: it won't catch all cases, but it won't suffer from false positives, so you can really scream bloody murder when it happens. Stefan