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: Wed, 23 Aug 2023 20:58:14 +0300 Message-ID: <83y1i1r689.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34363"; 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 Wed Aug 23 19:59:19 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 1qYs8U-0008iw-06 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Aug 2023 19:59:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYs8C-0005uI-7d; Wed, 23 Aug 2023 13:59:00 -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 1qYs8B-0005uA-Bg for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 13:58: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 1qYs8A-0002ZQ-Vr for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 13:58:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qYs8D-0003FV-Uc for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 13:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 17:59:01 +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.169281348712407 (code B ref 65451); Wed, 23 Aug 2023 17:59:01 +0000 Original-Received: (at 65451) by debbugs.gnu.org; 23 Aug 2023 17:58:07 +0000 Original-Received: from localhost ([127.0.0.1]:35127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYs7L-0003E3-Bw for submit@debbugs.gnu.org; Wed, 23 Aug 2023 13:58:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYs7F-0003DS-S6 for 65451@debbugs.gnu.org; Wed, 23 Aug 2023 13:58:05 -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 1qYs76-0002UQ-NC; Wed, 23 Aug 2023 13:57: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=pyOmhdRnJqnDB0FrYgeN7nFgDGTd4/jGzZyms90+1y0=; b=WyZnMqrhqWsY TZYiCzPKnpmR0qOYZIpkXE3gR0EEy3ftymgCSzZIbO3nRLzoDosro5iGkRN1QI1Q1G6OSfxFLkwpR hLiKjb8L1RPd/u1tyQMxI/iiOY2x4OfVMHiqh5+tIZHh2HjwhuUPftDG3tcKTh/x8JZtC+IQ7kHeX KvKnkw225pLbX3XEeCeQbk1GgQSTWSwYmLz3O8NJko+x91ZEds5s6aAlkqempi/JuBFQVkBarbwOP LieZBfYpLCefjstcacLcE82GpdqFGTLddgwxyHLa3pfEwXb7SqVtv2rbFJDwFVeYzNMhk+L6kq3Ug 7nI9wKdiD/20QSOFZ23f1w==; In-Reply-To: <874jkq87jl.fsf@localhost> (message from Ihor Radchenko on Wed, 23 Aug 2023 08:52:30 +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:268264 Archived-At: > From: Ihor Radchenko > Cc: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Wed, 23 Aug 2023 08:52:30 +0000 > > To update the old AST we need to know which regions in the old AST (and > old buffer text) were edited and their change in length. Then, we (1) > remove elements in AST that are structurally affected by the edit; > (2) shift elements after the edit that are not structurally affected but > whose boundaries must be adjusted to accommodate for the buffer length > being changed; (3) re-parse buffer text (after the edit) and fill the > gap in the AST. > > For step (1), it is critical to have information about changed regions > in the same order the edits happen. And, in theory, we might utilize > before-change-functions to obtain this information (assuming that > before-change-functions are always called in the same order the edits > happen). But, unfortunately, before-change-functions are too noisy for > this purpose because, for example, simply altering text properties also > triggers before-change-functions, while no actual change in buffer text > occurs in such scenario and re-parsing AST is unnecessary. So, we > instead have to use after-change-functions and work out the original > changed region boundaties using > beg_changed end_changed pre-change_lentgh -> > beg_before_change = beg_changed; > end_before_change = end_changed - pre-change_length > This calculation of the original changed region becomes incorrect when > the order of after-change-functions is not the same as the editing order > - this bug report. 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. > Indeed. As I tried to explain, the problem for me is not the granularity > of changes, but their ordering. I still don't understand why the ordering matters, but I do know that you cannot rely on it, and I hope I explained why.