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: Fri, 12 Nov 2021 15:09:15 +0200 Message-ID: <831r3lzfk4.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34863"; 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 Fri Nov 12 14:10:46 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 1mlWKL-0008tu-NM for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Nov 2021 14:10:45 +0100 Original-Received: from localhost ([::1]:36436 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlWKK-00054H-O3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Nov 2021 08:10:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33118) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlWJe-000536-3k for bug-gnu-emacs@gnu.org; Fri, 12 Nov 2021 08:10:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60390) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlWJd-00075W-R5 for bug-gnu-emacs@gnu.org; Fri, 12 Nov 2021 08:10:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mlWJd-0007sg-KA for bug-gnu-emacs@gnu.org; Fri, 12 Nov 2021 08:10:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Nov 2021 13:10: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.163672258430265 (code B ref 51766); Fri, 12 Nov 2021 13:10:01 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 12 Nov 2021 13:09:44 +0000 Original-Received: from localhost ([127.0.0.1]:43703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlWJL-0007s5-QT for submit@debbugs.gnu.org; Fri, 12 Nov 2021 08:09:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlWJG-0007ro-Ss for 51766@debbugs.gnu.org; Fri, 12 Nov 2021 08:09:42 -0500 Original-Received: from [2001:470:142:3::e] (port=35816 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 1mlWJB-00072v-N4; Fri, 12 Nov 2021 08:09:33 -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=e9ieklnT1NTlqSL/3owBfQ857XsAr7AnK5zYn+pJ8ao=; b=fth8AwWUZnDb 90ImWK4OxucVCUqoQecPI/Q+2kQBMSqUETSmGWGifcf3HYrRGgRSX7jzszcwmSN810i971+UB/HXm Rp5bDB4Tmh/UG2h1kyS6DHYe/dnKP20aqnqOrv7LyuAO2zrJb2g09vMx2HUWh3qLTnW2UBfAPyIIy g0m7sI/hk/jZN6AmWB443Hy2y0MKHLLmEkxFx16OSVkZXkuwEW8WL7Y7Jpye43zR8bwpNUk6RH+09 /WHpLPZNPWk9sWqRMjBTXQPT62jtl7tzKubKhzj+whYzptU3eQN5E3+42dRF81g5BlcugRYVAvPCF gH2qLWQyfaKKJ9D25YKfzw==; Original-Received: from [87.69.77.57] (port=3719 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 1mlWJB-0005Zn-BJ; Fri, 12 Nov 2021 08:09:33 -0500 In-Reply-To: <87zgq9pmb6.fsf@localhost> (message from Ihor Radchenko on Fri, 12 Nov 2021 20:53:33 +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:219771 Archived-At: > From: Ihor Radchenko > Cc: 51766@debbugs.gnu.org > Date: Fri, 12 Nov 2021 20:53:33 +0800 > > 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. OK, but why does this invalidate what Org does? All it means, AFAIU, is that in some cases Org will do unnecessary processing. Those cases are probably not too frequent. IOW, why invalidating the cache unnecessarily is such a big deal? > > 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. Would it help if Org looked at both buffer-modified-tick and buffer-chars-modified-tick?