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: Fri, 12 Nov 2021 20:53:33 +0800 Message-ID: <87zgq9pmb6.fsf@localhost> References: <87mtmalrs1.fsf@localhost> <837dde200c.fsf@gnu.org> <87k0helmig.fsf@localhost> <831r3m1tpk.fsf@gnu.org> <8735o1r31q.fsf@localhost> <834k8hzi10.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="26788"; 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 Fri Nov 12 13:53:09 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 1mlW3J-0006hN-5q for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Nov 2021 13:53:09 +0100 Original-Received: from localhost ([::1]:60684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlW3H-0000G1-ID for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Nov 2021 07:53:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58184) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlW3C-0000Fk-6g for bug-gnu-emacs@gnu.org; Fri, 12 Nov 2021 07:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlW3B-0004On-UB for bug-gnu-emacs@gnu.org; Fri, 12 Nov 2021 07:53:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mlW3B-0007SQ-J8 for bug-gnu-emacs@gnu.org; Fri, 12 Nov 2021 07:53: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: Fri, 12 Nov 2021 12:53: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.163672153628607 (code B ref 51766); Fri, 12 Nov 2021 12:53:01 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 12 Nov 2021 12:52:16 +0000 Original-Received: from localhost ([127.0.0.1]:43687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlW2R-0007RK-Mc for submit@debbugs.gnu.org; Fri, 12 Nov 2021 07:52:15 -0500 Original-Received: from mail-pg1-f181.google.com ([209.85.215.181]:37848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlW2P-0007R1-RL for 51766@debbugs.gnu.org; Fri, 12 Nov 2021 07:52:14 -0500 Original-Received: by mail-pg1-f181.google.com with SMTP id s136so7927294pgs.4 for <51766@debbugs.gnu.org>; Fri, 12 Nov 2021 04:52:13 -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=A2+6SjEdYlJq/uBw0f/fNWvurn/U5yWHWoZYX+o+CLQ=; b=q03I8wzBfqodydkcErBbTsi9DMamocH9fzlQctusP0lUPwEAClU0HCUBNWqFcFSi1o fFjqyQPSQIieGneD/MbMkKeUbErUVG5OjZMgksnN3hLdtXZdHNfQTaGx0u0YRnYm2Yf/ I07oBDNa37ZU8qUvxXu/FLx/JO7x4SQ/X2NaGNs+R2OXU3pZgorj/NmY7QsZgKJoBeys pbn/gUiWGIKvAwKAgsH50puxSgeV5eTLr3E+tH/9oun39NnjYEhPYNKBy+TDzixmmiD3 l+RyFB9WlvQvoQwx7wRThnhcy2k2JrTxbFDq2RaONG24Op0GoEX0vXrGwS+PavIHQv43 Peqw== 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=A2+6SjEdYlJq/uBw0f/fNWvurn/U5yWHWoZYX+o+CLQ=; b=LIg8Oo2DNh57lwjeOAGMyn5mIxSR3GMCf1Oo40BqsM49YxmWljrLwVwRBsMpDj7f6G eLE3gcZTI7B3VRuaTNKCQEv40S0A4QscXhsf5mpjf5Q9TKfyjpuMtAC4RELqMY9Ra939 iVCWSlxx7VM2uBZpW2Oc7WVe6ShSMnDch3oldgjGijDqedyjnk6tqpvBHSRMntgi1nvL /uLLjeWEs+Fiv+dU3uJA+QKbrsJGFo5o2br++M8AaZAvC/hJsl/pm9pL3J/ixWThNsyP B3TpQXNuBEe3/EF6wp3sRSVW70vWmKGW1MrsmalSsWimqUVu/9IX5cqQSGyG1qEDupxk I0TA== X-Gm-Message-State: AOAM533p+OslUAhp0EU2fn/SxpCboSOY6MduXUr9TWCoOHNG0mKztPbF 72S+URsBIb1jsLR0jVxqdLVNYwDT+O6Q1Q== X-Google-Smtp-Source: ABdhPJyVXDZdrL8UpJCEKXm80Mudy5b+dd3NaDBP9MLIQXLhG0Kp9RrLj0qBKXkgVCUDwlJxqN7VhQ== X-Received: by 2002:a05:6a00:c95:b0:49f:c8de:9ae7 with SMTP id a21-20020a056a000c9500b0049fc8de9ae7mr13827754pfv.30.1636721527873; Fri, 12 Nov 2021 04:52:07 -0800 (PST) Original-Received: from localhost ([103.125.234.210]) by smtp.gmail.com with ESMTPSA id f2sm6838086pfe.132.2021.11.12.04.52.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Nov 2021 04:52:07 -0800 (PST) In-Reply-To: <834k8hzi10.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:219768 Archived-At: Eli Zaretskii writes: > This last part I don't think I understand: why does quail's behavior > make the control code useless? The value returned by > buffer-chars-modified-tick still increases in your recipe, so what > exactly is the aspect of that behavior that makes the control code > useless? I think some additional details here are missing from your > description which could explain the issue. The control code makes sure that all the changes made in buffer are processed by org-element-cache. It means that org-element--after-change-function saves the buffer-chars-modified-tick and the next org-element--before-change-function checks if the saved value is unchanged. If the saved value is changed, the buffer has been changed after org-element--after-change-function, but before next org-element--before-change-function. Such change may be arbitrary and the whole cache is potentially obsolete. In code, the described roughly looks like: (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. )) quail changes the buffer after org-element--after-change-function call, but before org-element--before-change-function. So, all Org can see is that something has been changed in buffer, but there is no way to tell what it was. Org cannot distinguish between harmless buffer edits by quail (they do not change buffer text) and other kinds of "silent" changes. > I don't understand this, either. Are you saying that inserting a > character via an input method doesn't call buffer-modification hooks > even once? If the hooks are called, then what exactly is the problem > with the hooks in this scenario? The hooks are called, but after quail already triggered buffer-chars-modified-tick increase. If quail called before-change-functions before buffer-chars-modified-tick increases, it would be useful for my scenario. Though I am not sure how feasible it is. Just an idea. Best, Ihor