[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70077: An easier way to track buffer changes
From: |
Eli Zaretskii |
Subject: |
bug#70077: An easier way to track buffer changes |
Date: |
Sat, 30 Mar 2024 09:46:15 +0300 |
> Cc: Ihor Radchenko <yantar92@posteo.net>, 70077@debbugs.gnu.org,
> Yuan Fu <casouri@gmail.com>, Qiantan Hong <qhong@alum.mit.edu>,
> Frédéric Bour <frederic.bour@lakaban.net>,
> João Távora <joaotavora@gmail.com>,
> Nicolas Goaziou <mail@nicolasgoaziou.fr>, Alan Mackenzie <acm@muc.de>,
> Stephen Leake <stephen_leake@stephe-leake.org>,
> Alan Zimmerman <alan.zimm@gmail.com>
> Date: Fri, 29 Mar 2024 18:59:38 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> > If I remember correctly, I think this wouldn't be enough for my
> > use. You keep two buffers in sync, you have to use
> > before-change-function -- it is only before any change that the two
> > buffers are guaranteed to be in sync and it is this that allows you to
> > work out what the `start' and `end' positions mean in the copied
> > buffer. Afterward, you cannot work out what the end position because
> > you don't know if the change is a change, insertion, deletion or both.
>
> I believe the API I propose does provide that information: you can
> recover the state of the buffer before the change (or more specifically,
> the state of the buffer as of the last time you called
> track-changes-fetch) from the BEG/END/BEFORE arguments as follows:
>
> (concat (buffer-substring (point-min) beg)
> before
> (buffer-substring end (point-max)))
But if you get several changes, the above will need to be done in
reverse order, back-to-front, no? And before you do that, you cannot
really handle the changes, right?
> I don't mean to suggest to do that, since it's costly for large
> buffers
Exactly. But if the buffer _is_ large, then what to do?
> Also, it would fix only the problem of pairing, and not the other ones.
So the main/only problem this mechanism solves is the lack of pairing
between before/after calls to modification hooks?
- bug#70077: An easier way to track buffer changes, (continued)
bug#70077: An easier way to track buffer changes, Stefan Monnier, 2024/03/29
bug#70077: An easier way to track buffer changes, phillip . lord, 2024/03/29
bug#70077: An easier way to track buffer changes, Ihor Radchenko, 2024/03/30
bug#70077: An easier way to track buffer changes, Stefan Monnier, 2024/03/30