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 17:10:11 +0800 Message-ID: <87r1bkpgjw.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21961"; 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 10:09:14 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 1mlp2A-0005Yx-45 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 10:09:14 +0100 Original-Received: from localhost ([::1]:37892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlp28-0000Bw-RJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Nov 2021 04:09:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49868) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlp1y-0000Bo-TA for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 04:09:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34927) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlp1y-00054Y-Kh for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 04:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mlp1y-000864-Fg for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2021 04:09:02 -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 09:09: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.163679454031116 (code B ref 51766); Sat, 13 Nov 2021 09:09:02 +0000 Original-Received: (at 51766) by debbugs.gnu.org; 13 Nov 2021 09:09:00 +0000 Original-Received: from localhost ([127.0.0.1]:46473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlp1u-00085k-09 for submit@debbugs.gnu.org; Sat, 13 Nov 2021 04:09:00 -0500 Original-Received: from mail-pl1-f175.google.com ([209.85.214.175]:39873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlp1o-00085P-Vh for 51766@debbugs.gnu.org; Sat, 13 Nov 2021 04:08:56 -0500 Original-Received: by mail-pl1-f175.google.com with SMTP id t21so10336266plr.6 for <51766@debbugs.gnu.org>; Sat, 13 Nov 2021 01:08:52 -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=ryFEtk06tIoYlj7YUOeH2p4EIZpUgJ8JMDi/glZtwzY=; b=ArmevQfpd5GusSsln4ZQyNOMoXbeCVl3yh6PiUjdHMkPMTDBqwQkqOqxmRgJL2SUmZ OugAKMA4gHghlb3oCmrTSKaErmIill/qdQAoLbvB6rJiK4/jytSixUBNoVFwrnmg+7Hi hnT2VAEbJib5lA/LYURepJQgHbkJIwLAe97ui+9jlpcxSKo9ZGNtzPQq7KCqo4NTFflQ 8XP2k8OV5A8N/HGRsOR8DO3oCZC5so9jWql9kan3No4wcL6USAwj7nvxwkyLFdY2BLor n1m0JJRxqvJsOj0gjIp669CFY+oIF/HDRyxJbOR7rjrXe/Eftc8lPJOYUNdQFZN4rCKi 5SBQ== 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=ryFEtk06tIoYlj7YUOeH2p4EIZpUgJ8JMDi/glZtwzY=; b=h7klrWl0ZinuECuiVRIFGr203uOh7h8NPBfmKEV6cGn10uOmT4MKOAyonl/Gf+irgh KI6Uq+EgFAxIS09VZVI1aeuqrM8GMZPKXjpJJtYBnKgK4ioKqphHUvDgDsTHyugwhN2T FqRpI4rseYpsIsCGT32WjWaXzmud2GyqUCT1OZAFwANl2jP01GsmbGlmBWO83BYWz2kg EHEUbbJnx9fZIYUjXPseTz0MamOZp9f6P7FMGL9Q/yhKsXjSAIVut9C7lImTdwPK8E/I ne6qUmdqoC8cupkeEyLKiXV8JFV9e54qHmERL6dKqUDprugwlFKLQZMZhqhCQ8OtCxVG DXUA== X-Gm-Message-State: AOAM531EGWte71CDuise3Qs3zg1T+PbQlWp/IdUL1uZmpFQF36DPNI1H 5Q4+tYZ4uqSbR10oeRoGhhIRb/cq46Gn8Q== X-Google-Smtp-Source: ABdhPJzs/haJz/SQvdEUA2YeQl0UySOMRogdgR1VhoQ2e+J8gX2Mw2DBJXpB9O2rsH5IvVV0XdfR+w== X-Received: by 2002:a17:903:245:b0:13f:7872:9382 with SMTP id j5-20020a170903024500b0013f78729382mr15275395plh.26.1636794527181; Sat, 13 Nov 2021 01:08:47 -0800 (PST) Original-Received: from localhost ([103.125.234.210]) by smtp.gmail.com with ESMTPSA id e10sm10030308pfv.140.2021.11.13.01.08.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 01:08:46 -0800 (PST) In-Reply-To: <83zgq9xv1y.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:219800 Archived-At: 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")) Org cache is bound to track all the changes in buffer. Any missed change will lead to cache corruption. So, situations like the above must be tracked somehow. This tracking can be done using buffer-chars-modified-tick or buffer-hash/secure-hash. The latter is too slow. If I understand your earlier explanation correctly, quail for non-latin input (I tested with russian-computer) does something like (let ((inhibit-modification-hooks t)) (insert ?char) (backward-delete-char)) ;; This increases buffer-chars-modified-tick (insert ?translated_char_according_to_input_method) The change hooks will only be called for the last insertion. However, the first insertion+deletion will change buffer-chars-modified-tick. 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. > 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. Ideally, a way to track _all_ buffer modifications regardless of inhibit-modification-hooks would be useful. Currently, Org has to work around the possibilities that text can be inserted without triggering modification hooks: (1) when inhibit-modification-hooks/before-change-functions/after-change-functions are let-bound to nil; (2) when changes are made in indirect buffer with different buffer-local values of before/after-change-functions. Alternatively, Emacs could support language parsers. 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. Best, Ihor