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 (was: Tree-sitter integration on feature/tree-sitter) Date: Sat, 18 Jun 2022 10:01:48 +0300 Message-ID: <83mteao3oj.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1736"; 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 Sat Jun 18 09:07:13 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 1o2SY4-0000F9-VQ for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 09:07:13 +0200 Original-Received: from localhost ([::1]:35744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2SY2-0006t7-7K for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 03:07:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2SSv-0005hj-Uc for emacs-devel@gnu.org; Sat, 18 Jun 2022 03:01:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59170) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2SSu-000125-EV; Sat, 18 Jun 2022 03:01:53 -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=rJCqDybLmKQR/PdN40peTBgDostvWDgSwshS8+IIztU=; b=Gi7qV4jKL9JO GMP8W6ywYqZK+5fXKSjmbDQ94dgkziOC7uVj+Dy4waOO5fLj7YyM6dHRU7Nrt35vcohFedJ6a5boz UKacNXL/MIrUKsX4y91SpO3jVw5LElkarm2L90Mwzylak0r7dR7ZG/iDzMuOeMZyleyrosgMZJraG gnmKeI+9f95sQvfFC9TUvVmt5Bic0BXUEgX++HNYU2y/Qc+9b8xImZ1nLpHaepWoUmySQ+vyEF834 g0bc1Cfju5dIVdoNWXa2F/Bdd162TCaEJEnuM2sB8G93GBn/6VhBCLzIPitdNboi/cj1qdVN/eJhf HyjQANOfa8MK1NazkwjVfg==; Original-Received: from [87.69.77.57] (port=2482 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 1o2SSt-0004N2-T8; Sat, 18 Jun 2022 03:01:52 -0400 In-Reply-To: <878rpuwm9w.fsf@localhost> (message from Ihor Radchenko on Sat, 18 Jun 2022 13:52:59 +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:291339 Archived-At: > From: Ihor Radchenko > Cc: casouri@gmail.com, emacs-devel@gnu.org > Date: Sat, 18 Jun 2022 13:52:59 +0800 > > Org AST represents semantic objects using nested lists. > Similar to tree-sitter (AFAIU), each object in the tree is represented > by > > (object-type (object-plist) object-children ...) > > for example: > > * test headline :tag: > > is represented as > > (headline > (:raw-value "test headline" :begin 292 :end 314 ... :tags ("tag") ... :parent (...)) > ;; no children > ) > > Upon modifying text inside the headline, we need to update :begin/:end > properties to reflect the new headline boundaries in buffer and possibly > update headline properties (e.g. :tags). > > The same should be done for all the elements containing the headline. Where you care about changes in buffer positions of the AST elements, markers should take care of most, if not all, of them. I presume you already do use markers wherever possible? if not, why not? Or what am I missing? > Updating the elements require the following information: > > 1. Whether modified text contained terminal symbols or text contributing > to object-plist _before_ modification. > 2. The boundaries of the edited text in buffer and change in the text > length. > 3. Whether the modified text contain terminal symbols/text contributing > to object-plist _after_ modification. > > Org does not care about text property changes or overlay changes. > We just perform a series of regexp searches over the changed parts of > buffer (possibly with extended boundaries) before and after the > modification + know which region of text has been modified (its begin, > end, and change in length). > > Missing any significant change (the one involving terminal symbols or > changing region length) will make the AST invalid. Why would you miss significant changes if you base your implementation on buffer-modification hooks? If there are some situations where buffer text is modified in ways that are significant for the update of the AST, but buffer-modification hooks are NOT called, please describe some of those situations, so we will have something concrete to talk about. IOW, I still don't see from the above description why markers and buffer-modification hooks couldn't do the job, and you would need a lower-level hook into buffer text change machinery. I guess that would require a more detailed description of the job at hand?