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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: phillip.lord <at> russet.org.uk
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>
Subject: bug#70077: An easier way to track buffer changes
Date: Fri, 29 Mar 2024 18:59:38 -0400

> 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)))

I don't mean to suggest to do that, since it's costly for large
buffers, but to illustrate that the information is properly preserved.

> Last time I checked, I did find relatively few primitives that were guilty
> of being inconsistent -- in the case of `subst-char-in-region', it returned
> the maximal area of effect before the and the minimal area of effect
> after. Would it not be easier to fix these?

[ IIRC `revert-buffer` has a similar behavior, and in that case the
  difference can be large since the "before" covers the whole buffer.  ]

Also, it would fix only the problem of pairing, and not the other ones.


        Stefan

Previous Next

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