From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#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: Sat, 13 Nov 2021 15:38:13 +0200 Message-ID: <83k0hcxjju.fsf@gnu.org> 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> <83pmr4xt4c.fsf@gnu.org> <87o86opa3j.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28972"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51766@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 13 14:39:20 2021 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 1mltFY-0007La-7n for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 14:39:20 +0100 Original-Received: from localhost ([::1]:54298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mltFX-0006uw-99 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 08:39:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mltFG-0006uS-Nl for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 08:39:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35193) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mltFG-0005BF-Fk for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 08:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mltFG-000140-BF for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 08:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Nov 2021 13:39:02 +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.16368107204043 (code B ref 51766); Sat, 13 Nov 2021 13:39:02 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 13 Nov 2021 13:38:40 +0000 Original-Received: from localhost ([127.0.0.1]:46737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mltEt-000138-Td for submit@debbugs.gnu.org; Sat, 13 Nov 2021 08:38:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mltEq-00012s-SO for 51766@debbugs.gnu.org; Sat, 13 Nov 2021 08:38:38 -0500 Original-Received: from [2001:470:142:3::e] (port=50594 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mltEl-00057i-Kd; Sat, 13 Nov 2021 08:38:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xfHD4bgy9lKEHUuzNphoTQsCTqT/syIvLzX1FGiEWgk=; b=abxOHNQLJw6r oFkmNsaLkfDsEtIvIrhQawAmId4UiqQgiHFL1udgjxfDfyGfR/J7lvzJY7I5lI7yv5omH0pCNeMNb UvQ4WiU7fOKdC2KaPbSWLuzKYTWgodXQA4Zgz+IZr1NLLzMYnSeCFXbaz16y47Y4MPYPsFCGVhBf6 zx5pOF8f42B/YuBw43sZbUllgcNzkEQaXocuoKnq2AAiuQUYysDYMxeizPTxKy4bLKY4VDK0o0hGV aBTN4tywsR2W67PbU83mjJI9CPUqRjrP68JT98m7+tTCXHlO4zf8dswb/tZ5pwGa3zosXyc4oVfTo PMbwk5SYLxQOyMwhi/RqjA==; Original-Received: from [87.69.77.57] (port=3276 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mltEj-0007b6-3e; Sat, 13 Nov 2021 08:38:31 -0500 In-Reply-To: <87o86opa3j.fsf@localhost> (message from Ihor Radchenko on Sat, 13 Nov 2021 19:29: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:219811 Archived-At: > From: Ihor Radchenko > Cc: 51766@debbugs.gnu.org > Date: Sat, 13 Nov 2021 19:29:36 +0800 > > Eli Zaretskii writes: > > >> (let ((inhibit-modification-hooks t)) > >> (insert "Insertion that will never trigger before/after-change-functions")) > > > > So the problem is that Org uses the modification hooks as the primary > > mechanism (with which quail presents no problem), and > > buffer-chars-modified-tick as the fallback, and that when some code > > inhibits the modification hooks, then the primary mechanism cannot > > work and quail breaks the fallback? > > Not exactly. Org uses modification hooks as the only mechanism to > process buffer changes because Org needs to know the region where the > buffer text changes. buffer-chars-modified-tick is used for error > detection - when buffer text is changed, but Org modification hooks are > not called for some reason. quail triggers false positives during the error > detection. Is that any different from what I said, which is that you need error detection only when the modification hooks are not called? And that the quail behavior is only the issue when using this error detection, i.e. when the modification hooks are not called? > >> The quail's insertion+deletion itself is not a problem for Org cache - > >> it does not really alter the buffer text and cannot break the cache. The > >> problem is that it cannot be distinguished from the first example - both > >> cases will trigger buffer-chars-modified-tick increase. > > > > You didn't answer my question regarding buffer-modified-tick: it can > > explain to Org why buffer-chars-modified-tick jumped unexpectedly, and > > thus (hopefully) resolve this situation. If that helps, you could > > perhaps turn the table and use buffer-chars-modified-tick is the > > primary method of discovering changes, not as fallback. > > ... > >> The only assumption I had it that Emacs does not frequently change > >> buffer text without triggering modification hooks. Clearly, the > >> assumption was wrong. > > > > I meant the assumptions about what buffer-chars-modified-tick does and > > what its value means. > > It seems that we have some misunderstanding here. Org does not care > about the value of buffer-chars-modified-tick - just whether > buffer-chars-modified-tick is changed or not (see the above). But if buffer-modified-tick completely explains the change in buffer-chars-modified-tick, you can conclude that buffer-chars-modified-tick didn't change for your purposes, and then all's well, no? > Even if Org used the value of buffer-chars-modified-tick, it would not > be useful. There is no information about buffer region where the edits > happened if we just look at buffer-chars-modified-tick. AFAIK, only > after-change-functions have access to the changed region bounds. So what does Org do if the modification hooks were not called, and buffer-chars-modified-tick says the text was changed? > > But Org is not interested in just any moidification, AFAIU. It is > > only interested in modifications that change the buffer text. Isn't > > that true? Or what else is Org interested in for this purpose. > > You are right. Org is interested in modifications that change buffer > text. Also, Org is interested to be not affected by > inhibit-modification-hooks. Then maybe this is the missing infrastructure you'd like to see implemented. > > The Emacs code related to tree-sitter already uses change indications, > > and AFAIR didn't require any changes to the existing infrastructure. > > I wonder why Org cannot settle with what we have, if your needs are > > similar enough to those of tree-sitter. > > I just checked https://github.com/casouri/emacs/blob/ts/src/insdel.c > That ts Emacs branch directly modifies C-level Emacs buffer editing > primitives (see the calls to ts_record_change). So, it is not affected > by inhibit-modification-hooks. That's what I meant by "existing infrastructure".