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.devel Subject: Re: Exposing buffer text modifications to Lisp Date: Tue, 21 Jun 2022 12:36:14 +0800 Message-ID: <87wndar5tt.fsf@localhost> References: <2c2746e5f2558a87e8eab6f0914264a020173a9d.camel@pm.me> <27630AA3-8026-4E24-8852-ACCD9325B99D@gmail.com> <0E9E702B-B07C-4794-8498-29B9320E14CC@gmail.com> <871qvorqvv.fsf@localhost> <83tu8jq2vl.fsf@gnu.org> <87sfo37etn.fsf@localhost> <834k0jplcm.fsf@gnu.org> <878rpuwm9w.fsf@localhost> <83mteao3oj.fsf@gnu.org> <87edzmv3i0.fsf@localhost> <83k09eo1p5.fsf@gnu.org> <878rpuv17q.fsf@localhost> <83fsk2nyrm.fsf@gnu.org> <878rpr4kd4.fsf@localhost> <8335fzms6q.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="26056"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 21 06:35:47 2022 Return-path: Envelope-to: ged-emacs-devel@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 1o3VcB-0006cn-7E for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jun 2022 06:35:47 +0200 Original-Received: from localhost ([::1]:50484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3VcA-0004X4-8R for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jun 2022 00:35:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3VbX-0003od-DN for emacs-devel@gnu.org; Tue, 21 Jun 2022 00:35:07 -0400 Original-Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]:41686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o3VbV-0002Cr-P8; Tue, 21 Jun 2022 00:35:07 -0400 Original-Received: by mail-ot1-x32b.google.com with SMTP id q1-20020a056830018100b0060c2bfb668eso9843189ota.8; Mon, 20 Jun 2022 21:35:05 -0700 (PDT) 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=H77u4ephxxaQQJaRCbsLdfGrcxzH1vpaQdBOrxHlHgo=; b=p96mC4z6CXj1/Vy3e0JLO7ZX2BMf0+170vilGG4+lRBUI+pdYqv050WDCNGvpg4XhZ QLtGYZZzv2+Lf8p7Jpxa7SF0WcOe9M5m23RwkMmlTpGoHpwqOkmyhAGSFNZyHcz1Rhpt oA78jNehDuKHo3a5oJQ4O1MieX4/0Usz8lZrQRmwqc3GOhpT/ukGJz7hE2U4XHxtb2Uo XD/4/AIgYaV99kwJ6c0wkXEAYVFLsXTXqPKY/xY11c0d+f3bg8fZKiTHICNDZX3kaksf r10vXw42apUSMZJtT0gxbkEoX0F7pygw8CZjHF6gLPqGjkRLLMjkE+aZIzhk8eOvkCyg ahIg== 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=H77u4ephxxaQQJaRCbsLdfGrcxzH1vpaQdBOrxHlHgo=; b=V/+iiNqdYPN+EQ9iY2peuDIvJZcfSxcEetL/UE8GrL8qPNqhgvixgyudXrGC157Q7I jqlqf9553JgWDa1wF/zyqG/2mb2l1ULVB1Wv2vvmNM5gOHFd0YDL8nxhb7DIyDxadW1i aCrDwKlBDUfjrWmkrVHAphCeMrCrAkd8sPOocN3WuN4/80/GJuiPBOJyBbvlx/3kEQ7t ZOPU5Sn+JeOhsWodiMPCr6q8pfKSRsEj+2rwEx0mZ8DuRwDl2R64bb/sT/6MNJD+A0t0 BYdI8PkSIFXiUXcKycsRACw0l03NSvEVzGT9jazq9qECDZPeN3HpDqtZ3WfvKzGuoSvC RBmg== X-Gm-Message-State: AJIora/AOyCM01Wks0/YQiYRRaRvc3ffDqpnNwZhw0vnTJ8U9iPyR90b buvtvVmqYzMZd8l61A44ucDn8PHDsk4DLQ== X-Google-Smtp-Source: AGRyM1tXB+Ig/olYqD0Sv15Z81LSqwemehv6F9hjw6yUqahQv8O/JZReu+TLoC5w8h9FdbtVYStqqg== X-Received: by 2002:a9d:6a51:0:b0:612:9f70:8441 with SMTP id h17-20020a9d6a51000000b006129f708441mr5156510otn.384.1655786103976; Mon, 20 Jun 2022 21:35:03 -0700 (PDT) Original-Received: from localhost ([207.126.88.10]) by smtp.gmail.com with ESMTPSA id r3-20020a056870734300b000e686d1386dsm8470798oal.7.2022.06.20.21.35.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jun 2022 21:35:03 -0700 (PDT) In-Reply-To: <8335fzms6q.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::32b; envelope-from=yantar92@gmail.com; helo=mail-ot1-x32b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291480 Archived-At: Eli Zaretskii writes: >> Does Emacs C code provide any generic tree structure implementation? > > We have interval trees and red-black trees, but they are used for > specific C-level features, and I wouldn't call them "generic". > > OTOH, don't you want to create a Lisp structure to represent AST? If > so, C-level tree will not really help you, would it? Clarification: I was asking about C-level trees to store marker list. I did not have moving Org AST from Lisp to C-level in mind. We currently use built-in Lisp implementation of AVL-tree to search across AST (which is not ideal, but good enough for moderately large files). >> Also, markers will not solve all the needs of Org parser even when they >> become more efficient. As I mentioned earlier, we also need to keep >> track whether terminal symbols appear in the changed text before/after >> modification. It boils down to matching regexps around changed region in >> buffer before/after each modification. Suppressed >> before/after-change-functions ruin this logic as well. > > I asked a question about that, but you said you wanted to answer the > AST-related parts first. So can we now go back to this aspect to > understand it better? This is still somewhat related to AST. AST object properties that do not refer to positions in buffer may still need to be updated upon buffer modification. For example, consider * TODO headline being changed into * DONE headline with (with-silent-modifications (search-foward "TODO") (replace-match "DONE")) or even simply by (replace-match ...) inside indirect buffer created by direct call to make-indirect-buffer. The AST headline object will need to be updated from (headline (... :todo-keyword "TODO" ...)) to (headline (... :todo-keyword "DONE" ...)) > Emacs inhibits buffer-modification hooks when > it is quite sure Lisp programs "don't need to know" about those > modifications. One example you cited where this bites you is use of > input methods. But Quail doesn't inhibit the hooks completely, it > only inhibits them enough to pretend that just one character was > inserted, when the user might have inserted more. So why does this > get in the way of the Org parser, if the modification hooks are being > called "enough"? It does not. Given that I implement the suggestion about using buffer-size to track "missed" modifications, Quail will not be an issue anymore. The only potential problem that will remain is the type of buffer modifications I described above (shielded by inhibit-modification-hooks or by being done inside indirect buffer). If such modifications do not change the buffer size (as above), we still get a problem that may (although less likely) cause data loss on user side. > Thus, the difference between these two approaches is not whether or > not to add new features to core (which understandably makes the job of > developers of packages like Org harder due to support of older > Emacsen), the difference is _which_ new features to add. I'm saying > that it is much better to add features which will avoid your jumping > through hoops, instead of adding features that will allow you to jump > through hoops faster and better, so to say. It is better also in the > long run, because it helps Emacs development as well, and it helps you > and other 3rd party packages that will be able to use those new > features for future implementations. I totally agree. Though additional consideration is LOC cost of adding new features. As you can see, I took a lazy approach in this request. Adding a new hook would not require much code change on Org side. In contrast, changing implementation to markers will actually require careful testing and a lot more LOC changes. So, we have a clash between "faster" and "better" :) In any case, I totally get your position and I do know that Emacs core should not accept low-quality features just because they are going to be easier for some single specific use-case. I would do the same if I were to maintain Emacs. > This can unfortunately happen with any discussion, and is not always > under our control. Perseverance is the only way I know of to prevail > in those cases. I understand. Unfortunately, it also creates mental friction on my side despite this understanding. I will submit patches via debbugs in future to make things more visible. Best, Ihor