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.devel Subject: Re: Exposing buffer text modifications to Lisp Date: Tue, 21 Jun 2022 15:27:27 +0300 Message-ID: <831qvikxqo.fsf@gnu.org> 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> <87wndar5tt.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16154"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 21 14:30:46 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 1o3d1p-0003yC-Tq for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jun 2022 14:30:46 +0200 Original-Received: from localhost ([::1]:34862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3d1o-0006H2-PM for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jun 2022 08:30:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3cys-0002uC-KV for emacs-devel@gnu.org; Tue, 21 Jun 2022 08:27:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43558) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3cyr-0000IH-AF; Tue, 21 Jun 2022 08:27:42 -0400 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=isOYo5wwEbxH/Lqfk7w+XrHCfXNCmpHC2jgaYC6ir3o=; b=XBL3T83wOpcp tE2cNPo5Y+7cWMnofiwKMVsn54QkIxRwPBvqxrnLcow/D4hEvcc8SHpJLXE0S57cOsi3PYrCQhCea 1q2pjZL+LaYwYB8X50jO01i+ZaaWS4jc5xHkEXt1iBbU7SQ6MQGbtC+tCtYNc7rd9LaMUf+ve5EQU GfFbVbwEnrjxbGvoPJp1pTCBw5oOLnFxn3Ac5j90lJLRu15cVYhCXxPET4CmSC4ytl8QF2NRzDQ5m p21YO7Fm5y/3DWRhWsoXlbQWcCc26iydWWYH9G9hLBb4WrfxMZfdKn5CyE19ECetOt5EpEa7Ff6D4 NzTCxd3Kic5DyBkHkWpdog==; Original-Received: from [87.69.77.57] (port=1194 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 1o3cyp-0008Pw-IM; Tue, 21 Jun 2022 08:27:41 -0400 In-Reply-To: <87wndar5tt.fsf@localhost> (message from Ihor Radchenko on Tue, 21 Jun 2022 12:36:14 +0800) 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:291489 Archived-At: > From: Ihor Radchenko > Cc: casouri@gmail.com, emacs-devel@gnu.org > Date: Tue, 21 Jun 2022 12:36:14 +0800 > > > 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). Ah, okay. Sorry for my misunderstanding. Trees could indeed be relevant, but maybe other data structures as well? E.g., why not hash tables? Not that I consider myself an expert on efficient search algorithms... > 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. I'd consider such Lisp programs buggy. Actually modifying a buffer while concealing the entire modification is evil. > I will submit patches via debbugs in future to make things more > visible. TIA.