From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 19:29:36 +0800 Message-ID: <87o86opa3j.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31022"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51766@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 13 12:29:25 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 1mlrDk-0007d1-V9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 12:29:21 +0100 Original-Received: from localhost ([::1]:50420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlrDj-0001DK-Sw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 06:29:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlrDS-0001D6-9k for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 06:29:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35118) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlrDS-0004QV-1h for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 06:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mlrDR-0003lx-RY for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 06:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Nov 2021 11: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.163680290114443 (code B ref 51766); Sat, 13 Nov 2021 11:29:01 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 13 Nov 2021 11:28:21 +0000 Original-Received: from localhost ([127.0.0.1]:46664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlrCn-0003ks-9Y for submit@debbugs.gnu.org; Sat, 13 Nov 2021 06:28:21 -0500 Original-Received: from mail-pj1-f52.google.com ([209.85.216.52]:44992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlrCk-0003kc-0x for 51766@debbugs.gnu.org; Sat, 13 Nov 2021 06:28:19 -0500 Original-Received: by mail-pj1-f52.google.com with SMTP id o6-20020a17090a0a0600b001a64b9a11aeso9757983pjo.3 for <51766@debbugs.gnu.org>; Sat, 13 Nov 2021 03:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=EFMmPOLGS3u78zRooj/cHCyM7/X8b3yHHGC9AntuNYI=; b=NGDpdaQhACLelAOjBwSUDFIeqWfEBaCfeKomG4DgRYh7Ck31DSzsiDuemfhKUE79uv 2eXWnLu2NrQ6mrsI6asXxy6oIMwifd+TzuHgu79hCf+Bg+ym2rbu1nrHInqmtEZ89OfV Wecst+yiDPEfZhh9hh7viUy3ijjszgZHmE+772i7mR608AQYhnp3ZyY5Kmfg5DhnJSq6 EeuXIuX0W7R5UGNwDUPEj7V4/Hi8awBj1DEbXiL+rWDHL+VDHRh8nk60Sjvm3vW8E74C 1p8DkU5uHY6utWZdwg5JS9IBrF4iACeHm9gyOQhKfp0ROEuYkUGfI2xOSPkSKS4Vb6gc xN+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=EFMmPOLGS3u78zRooj/cHCyM7/X8b3yHHGC9AntuNYI=; b=v/5PfPkP1FYjsVhm+1sGDw0RYHH1BygLxNBLPEJVLz1tHcSe7Q/Q7IgK/i/F9BGOXB HN6j9VPYY+zCtr8ux4SIL2PfAFlTBjZc4DEu+ena+gS7I9IPsXDEJ4Qd453h+M5lpOP/ OliPiguspGz+E7wP072gDni+b6bvbJTjd54K/JqPhH9YJW7V5TJJRDvhydgEM65ImJhM xlrlkRStz1KUAmVw68Tj6Ad4/9j5/f7F4XDYtjjjbPmHuUvquGZikrE5bkNNgweQFNV1 lf3iaZd1oQRq5oL50ACUq5a1+USKzM8NAXcRE1q0Hnf5B2PWMDDzDTcmk1o7IrYAeMcx R4ng== X-Gm-Message-State: AOAM531uP9EMb27YF7oqKR0MDX53NQw276wnz4i29sKXgc5DfgJ2Bs/a kt/tjq1tsKRX6BoWmgzYCjVjRpxmMa07qA== X-Google-Smtp-Source: ABdhPJxiwshJNMEc4qKho0DvkJikcmL8CSTnYoNMHqdn/lASnV9ZGvD3oHTbXnuMMB6/2sw9ol+2DQ== X-Received: by 2002:a17:90b:4c85:: with SMTP id my5mr26020772pjb.26.1636802892115; Sat, 13 Nov 2021 03:28:12 -0800 (PST) Original-Received: from localhost ([103.125.234.210]) by smtp.gmail.com with ESMTPSA id i5sm7204008pgo.36.2021.11.13.03.28.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 03:28:11 -0800 (PST) In-Reply-To: <83pmr4xt4c.fsf@gnu.org> 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:219806 Archived-At: 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. >> 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). 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. >> Ideally, a way to track _all_ buffer modifications regardless of >> inhibit-modification-hooks would be useful. > > 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. Making sure that Org modification hooks run for every modification is automatically making sure that no modifications that do change buffer text are missed. I thought that it can be the simplest approach to fix the issue. >> Alternatively, Emacs could support language parsers. > > I meant support on the low level, where changes to buffer text are > considered and indicated. As I indicate below, the integration of > tree-sitter simply uses the existing change indications, so I'm not > sure how would a parser support help you in this matter. I probably went too far with my suggestion here. I meant not only handling changes, but also adding API for working with syntax trees using C-level functions. It is out of scope of this bug report. > 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. Best, Ihor