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.bugs Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Date: Thu, 24 Aug 2023 11:08:16 +0300 Message-ID: <83zg2gq2vj.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5216"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 65451@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 24 10:09:17 2023 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 1qZ5P2-00017u-UO for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Aug 2023 10:09:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZ5On-00056A-Fb; Thu, 24 Aug 2023 04:09:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZ5Ol-00053d-86 for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 04:08:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qZ5Ok-0002zb-Vw for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 04:08:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZ5Oo-0002gZ-BX for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 04:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 08:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs Original-Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169286448510254 (code B ref 65451); Thu, 24 Aug 2023 08:09:02 +0000 Original-Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 08:08:05 +0000 Original-Received: from localhost ([127.0.0.1]:36067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ5Ns-0002fK-Sb for submit@debbugs.gnu.org; Thu, 24 Aug 2023 04:08:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ5Nq-0002el-Fv for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 04:08:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZ5Ng-0002rD-UN; Thu, 24 Aug 2023 04:07:52 -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=lBJw0q221Airh9YICpczvSgbTpqsbdGw/jenVhkNDdQ=; b=X/cjkLZ5lZ6Q VyQ6m4n8s1S5brgs5JXCFunFiYKshaa8Dl5eKXplQNJGhjkPCDHZrWLlt32PS1pNruH9R/PvEO6Pn Gl/wtGtJSGnuExH9FjhnerMhGsQMpVOiPv8XOKcK+pv0o9u4kmcyYopsrG4eGIapejgSyhUjf2w1g k2eISv8R77S7AEngZx5TTEp4tWKiEtqIHm7iRWVlnpAxKjMXBvDbt5lJMCu3i8YFROgyMzCyjjEq7 YmO1YlPRC9wFy8T4CyVQyLeRNtiGvpQAvtShSudokDo9arHmAZjQEB92ATa1DOGEQTOIRbvA1pqzi MMqev//oiTX+28sgEfqP1A==; In-Reply-To: <87fs487uip.fsf@localhost> (message from Ihor Radchenko on Thu, 24 Aug 2023 07:46:06 +0000) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268314 Archived-At: > From: Ihor Radchenko > Cc: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Thu, 24 Aug 2023 07:46:06 +0000 > > Eli Zaretskii writes: > > > If these measures still don't help you enough, perhaps the conclusion > > is that it isn't feasible to implement text parsers in Lisp, at least > > as long as you want all those micro-optimizations of knowing exactly > > which parts of the buffer text were modified (as opposed to only know > > how many characters at the beginning and at the end of the buffer > > remain unchanged, and reparse the rest). Maybe it must be done in C, > > if we want Emacs to remain a relatively safe environment. > > Do I understand correctly that `treesit_record_change' is called > __less frequently__ compared to before-change-functions and > after-change-functions? No, treesit_record_change is called at a lower level than buffer-change hooks are, and therefore in some cases the hooks will not be called, but treesit_record_change will be. The frequency might be lower, but only because treesit_record_change is called once per change; there's no separate "before" and "after" calls. In any case, the correspondence is not 1:1, because they are called on different levels. > If yes, I do not see how exposing it to Elisp will make things any > worse than already available > `before-change-functions'/`after-change-functions'. Exposing buffer text changes to Lisp is inherently dangerous, because Lisp code can do anything and everything in these hooks, and many packages already do. The fact that we allow this via those two hooks is unfortunate as it is, but adding more opportunities for Lisp to do potentially dangerous stuff, and doing that on a lower level, where the buffer object is sometimes in a state that is not 100% consistent, is unwise, to say the least. It will make Emacs much less stable. No, thanks.