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 (was: Tree-sitter integration on feature/tree-sitter) Date: Sat, 18 Jun 2022 15:23:51 +0800 Message-ID: <87edzmv3i0.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39224"; 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 Sat Jun 18 09:24:33 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 1o2Sor-000A2C-PZ for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 09:24:33 +0200 Original-Received: from localhost ([::1]:45812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2Sop-000696-DJ for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 03:24:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2SnA-0005Mh-O4 for emacs-devel@gnu.org; Sat, 18 Jun 2022 03:22:48 -0400 Original-Received: from mail-qv1-xf2d.google.com ([2607:f8b0:4864:20::f2d]:39929) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o2Sn8-0008SH-Qs; Sat, 18 Jun 2022 03:22:48 -0400 Original-Received: by mail-qv1-xf2d.google.com with SMTP id cs6so4904242qvb.6; Sat, 18 Jun 2022 00:22:45 -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=R5wGFdzbVySd9lZW+S/hPcv6ot05rYZOvEPd9Stxc9o=; b=fNA+sJ75MV9xpOnd4dypU58P4Jh2CINqUq85MZ57u8m7GUokruVmMMWJQ/kqUuQIGX nUWjisSde2UpYfiWhJ/drCcy6S4aYk/bBXrQNFUfbhwBErsSol5zmHu0E/mT18Wm/KjB mlO6aAFTBtgsK5RiENXnO3NcG0z5xbIftv6aON/MB0qrRwlXAtndq9sdQgWBK5MP4xDG AHVq/1yBnm+2VU6kNaqLvlzYhfybGMWDh70S5ZGwd7I1AUik+CBH5KPSsMgrRrF2vjl7 Dsv4tzV8ZpJAkMK4oH6JEBuhrrmiXIZwZwh5PLOnNCIlJEMU4gJn9EB0dTJjyWMK7bq/ DBOQ== 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=R5wGFdzbVySd9lZW+S/hPcv6ot05rYZOvEPd9Stxc9o=; b=6saKeb2uxha+F4o9QNucm399JeptBVyge7N78ycclp1eSF93SGsn0uvkL3UBTclTmz 45Mt8LVUfT4i5ArZtNOwnQTIka9NynrelWnS0+MJJ3NqO+VmYxfa0JnQFKT/ZJkbasvl ZE0rkkKOQ+6HwGz9Z/bV1cF/L+0Xi7SzDc9fY3x1sD3c0hRDwlJ96vL0U/COW9lQa+ca hFXTcg84TFIg2Ly/4yN6ylghHpKWmoXyIeYXxvSbw5mEecAKpuN714iYbVwvFRespWjp HO++vr3TVPpifIZCKN9vVr6xVJ+1w/4YqkxzTgFcz1W6y+awtszMGd/7wsJduL/DtCqr g4Zg== X-Gm-Message-State: AJIora9c09LWbsFfULD2nrH+QBgmOOOLSAl1SDYV+XAkBj+tskkko/cu YUDTcYrNUpleGzWfPqjgDWf9fEy9ccTVKprD X-Google-Smtp-Source: AGRyM1vK6621kEX8Y+kAF62ain65Nt/CfkY13SaVwlkWfzgojMlkZ+k0gDh/akxBM8IbEJ2DQ6046g== X-Received: by 2002:ac8:594e:0:b0:304:d914:2ef8 with SMTP id 14-20020ac8594e000000b00304d9142ef8mr11661512qtz.149.1655536964984; Sat, 18 Jun 2022 00:22:44 -0700 (PDT) Original-Received: from localhost ([204.44.110.111]) by smtp.gmail.com with ESMTPSA id h13-20020a05620a284d00b006a6bd7028d5sm6268145qkp.18.2022.06.18.00.22.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jun 2022 00:22:44 -0700 (PDT) In-Reply-To: <83mteao3oj.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::f2d; envelope-from=yantar92@gmail.com; helo=mail-qv1-xf2d.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:291341 Archived-At: Eli Zaretskii writes: >> (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? Because lots of markers degrade Emacs regex search performance tremendously. See https://list.orgmode.org/orgmode/scedec$2g0$1@ciao.gmane.io/ and https://orgmode.org/list/87y21wkdwu.fsf@localhost >> 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. The situation is third-party code doing bloody murder with (with-silent-modifications (insert "Some text not triggering modification hooks)) Another scenario is modifying text in indirect buffers created with make-indirect-buffer. (where there is no chance to install before/after-change-functions via clone-indirect-buffer-hook). Best, Ihor