Re: Thinking about changed buffers

[Florian Weimer]

On 03/28/2016 07:31 PM, Lars Magne Ingebrigtsen wrote:
> In conjunction with the wishlist item "`M-q' shouldn't say that the
> buffer hasn't changed when it hasn't", we started talking a bit about
> further issues about what it means that a buffer has changed or not.
> 
> If you load a file, and then hit "a", and then delete the "a", then
> Emacs will say that the buffer has changed.  If you hit "a" and then
> `undo', Emacs will say that it hasn't.
> 
> If there was a way to deal with this discrepancy, that would be very
> nice, I think.

I feel a bit silly, but I rely on this discrepancy (SPC DEL marks the
buffer as changed) so that saving the buffer is an actual operation
which updates the file timestamp, to trigger a rebuild of its dependencies.

> One idea that popped up is that whenever we mark a buffer as unchanged
> (that is, `(set-buffer-modified-p nil)', we save the byte size of the
> buffer and a cryptographic hash of the buffer.  Then `buffer-modified-p'
> would simply see whether either the size had changed, and if not,
> whether the hash had changed.  If both are identical, then the buffer
> hasn't changed.

For me, the major nuisance is that Emacs claims that the file has
changed on disk, when it fact it hasn't—the mtime changed, but the
contents is the same.  At least it's easier to detect this case with the
hashing approach you propose.

Florian