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.