GNU bug report logs - #70077
An easier way to track buffer changes

Previous Next

Full log

Message #29 received at 70077 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: yantar92 <at> posteo.net, 70077 <at> debbugs.gnu.org, casouri <at> gmail.com,
 qhong <at> alum.mit.edu, frederic.bour <at> lakaban.net, joaotavora <at> gmail.com,
 mail <at> nicolasgoaziou.fr, acm <at> muc.de, stephen_leake <at> stephe-leake.org,
 alan.zimm <at> gmail.com, phillip.lord <at> russet.org.uk
Subject: Re: bug#70077: An easier way to track buffer changes
Date: Sat, 30 Mar 2024 09:46:15 +0300

> Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 70077 <at> debbugs.gnu.org,
>  Yuan Fu <casouri <at> gmail.com>, Qiantan Hong <qhong <at> alum.mit.edu>,
>  Frédéric Bour <frederic.bour <at> lakaban.net>,
>  João Távora <joaotavora <at> gmail.com>,
>  Nicolas Goaziou <mail <at> nicolasgoaziou.fr>, Alan Mackenzie <acm <at> muc.de>,
>  Stephen Leake <stephen_leake <at> stephe-leake.org>,
>  Alan Zimmerman <alan.zimm <at> 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 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.