From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70077: An easier way to track buffer changes Date: Mon, 01 Apr 2024 13:49:48 -0400 Message-ID: References: <86frw8ewk9.fsf@gnu.org> <86cyrcdy80.fsf@gnu.org> <877chh8fjk.fsf@localhost> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9768"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: casouri@gmail.com, 70077@debbugs.gnu.org, qhong@alum.mit.edu, frederic.bour@lakaban.net, joaotavora@gmail.com, mail@nicolasgoaziou.fr, acm@muc.de, Eli Zaretskii , stephen_leake@stephe-leake.org, alan.zimm@gmail.com, phillip.lord@russet.org.uk To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 01 19:51:13 2024 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 1rrLoO-0002MT-Qc for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Apr 2024 19:51:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrLoC-0006Hm-Ue; Mon, 01 Apr 2024 13:51: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 1rrLoA-0006HM-T8 for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2024 13:50: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 1rrLoA-0004hk-Jp for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2024 13:50:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rrLoD-0002W8-JM for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2024 13:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Apr 2024 17:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70077 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70077-submit@debbugs.gnu.org id=B70077.17119938039601 (code B ref 70077); Mon, 01 Apr 2024 17:51:01 +0000 Original-Received: (at 70077) by debbugs.gnu.org; 1 Apr 2024 17:50:03 +0000 Original-Received: from localhost ([127.0.0.1]:51499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrLnG-0002Um-UF for submit@debbugs.gnu.org; Mon, 01 Apr 2024 13:50:03 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrLnE-0002U9-QS for 70077@debbugs.gnu.org; Mon, 01 Apr 2024 13:50:01 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7C59180B3D; Mon, 1 Apr 2024 13:49:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711993790; bh=VQHhZUhpG2vP8s07j656OeU+juE05tho/VcNcY6O10c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dgCgENIJ0EeQRg8CIbm+X3SCyigVLX0zg4QQDsHmklnGrRqjXPD0uAwEHHuXjhgp1 uyCfQ7ISmCCyoDp67RuAPKSKKnAGsp4g1MvVYIhBtGx7CSt75yvCtm96Hs94Wccp3e /Lcd7ZJhCpLrBF/M7XAi5SuJTWEMqYrN1LjzzTRGkgaSoAnbm7pV5pqpfJIzqaj333 VHyLHTsY/r7ImeyPWiu2kXVAS7RY4aWxTm9amedEawqwKHFU5lUYxc2h6ImJ2Z7Jmk Ee7NomeJ8sp3VzXsTLONnOiIx6n3oCDaJZcSx8dctku+ldLNu1cSl1LUHoRBDT4Pgp W8Gx7NFB6JDpw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1ECF5806EF; Mon, 1 Apr 2024 13:49:50 -0400 (EDT) Original-Received: from alfajor (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AAA7512046C; Mon, 1 Apr 2024 13:49:49 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Mon, 01 Apr 2024 10:51:53 -0400") 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:282485 Archived-At: >>> ... That's why `track-changes.el` bundles those into a single (BEG END >>> BEFORE) change, which makes sure BEG/END are currently-valid buffer >>> positions and thus easy to use. >>> The previous buffer state is not directly available but can be >>> easily reconstructed from (BEG END BEFORE). >> Do I understand correctly that such bundling may result in a situation >> when BEFORE is very long? In particular, I am thinking of a situation >> when there are changes near the beginning and the end of buffer in quick >> succession. > Yes! I'm not sure how to combine the benefits of combining small changes into larger ones with the benefits of keeping distant changes separate. I don't want to expose in the API a "sequence of changes", because that's difficult to use in general: the only thing a client can conveniently do with it is to keep their own copy of the buffer (e.g. in the LSP server) and apply the changes in the order given. But if for some reason you need to do something else (e.g. convert the position from charpos to line+col) you're in a world of hurt because (except for the last element in the sequence) you don't have easy access to the state the buffer was in when the change was made. We could expose a list of simultaneous (and thus disjoint) changes, which avoids the last problem. But it's a fair bit more work for us, it makes the API more complex for the clients, and it's rarely what the clients really want anyway. But it did occur to me that we could solve the "disjoint changes" problem in the following way: signal the client (from `before-change-functions`) when a change is about to be made "far" from the currently pending changes. The API would still expose only (BEG END BEFORE) rather than lists/sequences of changes, but the clients could then decide to record disjoint changes as they occur and thus create&manage their own list/sequence of changes. More specifically, someone could come a create a new API on top which exposes a list/sequence of changes. The main downside is that this signal of "upcoming disjoint change" would have to be called from `before-change-functions`, so the client would need to be careful as usual (e.g. don't modify the buffer, don't do any blocking operation, ...). Stefan