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 12:11:31 +0200 Message-ID: <83pmr4xt4c.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32434"; 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 11:12:17 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 1mlq1A-0008GE-5a for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 11:12:16 +0100 Original-Received: from localhost ([::1]:35052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlq18-0003hT-R5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 05:12:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlq12-0003gv-4q for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 05:12:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35031) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlq0w-0004BN-K0 for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 05:12:07 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mlq0w-0001OX-Br for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 05:12: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 10:12: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.16367983185348 (code B ref 51766); Sat, 13 Nov 2021 10:12:02 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 13 Nov 2021 10:11:58 +0000 Original-Received: from localhost ([127.0.0.1]:46577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlq0r-0001OC-N0 for submit@debbugs.gnu.org; Sat, 13 Nov 2021 05:11:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlq0m-0001Nw-KS for 51766@debbugs.gnu.org; Sat, 13 Nov 2021 05:11:55 -0500 Original-Received: from [2001:470:142:3::e] (port=46954 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 1mlq0h-0004AN-EZ; Sat, 13 Nov 2021 05:11:47 -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=L+XgwkivAdSwZxNO5aCOYBze1zcwo7bFJOxaZxXWQy4=; b=YPmwQBRVV/Jb ghnCCIx9GC3Z63WYzM6eoX5FEbr87VbexQPgNh2xLybECfdtEKqBJe3yP9lmLNXE5yB/TyJHD3Coy BhhMykNP8FCppKbHTw9JMtIx3sZaXcvVdRQ6CMlM/srgCHpocfqkdUores/ncvxKmGOJzASW0mINR 0h4x2mIyGK9EEP8Wjr88dTu4lk85aagq2tlvmep+LmhCBpQkKvuSn3K8qiWBEXkBK/PUdGj9qBeW4 vdHbXq8HNj83JrNV77ROOXZiagHqJLADDFRGe5aa/89gfjOOipgujF+3awIMFGEjM5Mg5ZUInDa/b GjLAxIEslxCVR9KcAC1B5g==; Original-Received: from [87.69.77.57] (port=1914 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 1mlq0h-0005Lz-2c; Sat, 13 Nov 2021 05:11:47 -0500 In-Reply-To: <87r1bkpgjw.fsf@localhost> (message from Ihor Radchenko on Sat, 13 Nov 2021 17:10:11 +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:219804 Archived-At: > From: Ihor Radchenko > Cc: 51766@debbugs.gnu.org > Date: Sat, 13 Nov 2021 17:10:11 +0800 > > Eli Zaretskii writes: > > > "Such change" being what exactly? the situation where > > buffer-chars-modified-tick changes between post-command-hook and the > > following pre-command-hook? or something else? > > The former. > > > So what exactly is the problem with these hooks when non-latin input > > methods are used? Or what am I missing? > > There is no problem with the hooks in your example. However, consider > the following: > > (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? > 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. > > Perhaps Org developers should ask for infrastructure changes that will > > allow Org to maintain such a cache reliably and not too expensively? > > It sounds like Org currently applies all kinds of heuristics based on > > assumptions about how the internals work and using hooks and features > > that were never designed to support this kind of caching. Jumping > > through hoops in Lisp trying to implement something that might be much > > easier or even trivial in C is not the best way of getting such jobs > > done. > > > > So perhaps someone could describe on emacs-devel what does Org need to > > maintain this cache, and we could then see how to provide those > > features to Org. > > I am one of the Org developers. > > 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. > 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. > 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. > Org cache > implements editing syntax tree generated by Org element parser. It is > very similar to what tree-sitter editing API does: https://tree-sitter.github.io/tree-sitter/using-parsers#editing > > Native support for storing, modifying, and querying syntax trees using > efficient data structures could be a great addition to Emacs from Org's > perspective. Though it is not an easy feature to implement. > > AFAIR, something similar to my last suggestion has been already > proposed: tree-sitter support. I can also propose the first idea about > reliable buffer change tracking if you think that it is something > reasonable. 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.