bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> I don't think so. It could be auto-disabled for large buffers and the
>>> check would only take place when the size of the buffer is the same as
>>> the size of the original file.
>>
>> Oh yeah, that's true...  Except for the problem with the text
>> properties.  :-)
>
> Oh yes, apparently the fix for this bug must be bug-compatible with the
> feature it is fixing.

:-)

But, come to think of it, I think it's quite rare in practice to do a
lot of text property related editing without changing the size of the
buffer, so perhaps this doesn't matter much.  I mean, if you have a work
flow that involves you opening a 2GB file, and then placing text
properties (unrelated to font-locking) all over the place without
changing the buffer otherwise, then...  you're probably kinda unusual?

So the "only hash when the buffer size is the same as when you loaded
the file" thing would probably avoid the hashing in more than 99% of the
use cases.

>> I think I'd want the "buffer changed" indicator to reflect the state
>> immediately after doing an edit, though.  It's been a long-standing
>> annoyance that Emacs claims that the buffer is changed when it "kinda
>> isn't" (i.e., insert "a" and then delete it).  I want to see that
>> immediately in the mode line.
>
> Agreed. As long as the file is small enough for the hash function, an
> idle timer with a short span would do. We don't want the hashing running
> again and again while some command does multiple changes to the buffer.

But I really think it has to be immediate and predictable for Emacs to
keep working as it does.

I mean

(progn
  (find-file "~/foo")
  (insert "zot")
  (save-buffer))

must work reliably.

One argument against switching to hash based edition detection is that
we'd have a different method of computing the change when we have a
buffer visiting a file and not...  or...  perhaps not?
`(set-buffer-modified-p nil)' could be the function that computes the
"initial" hash'n'size that would be used later, and `buffer-modified-p'
could just compare with that tuple...

This would allow us to get rid of the...  er...  thing that keeps track
of buffer modification now...  is that the text->modiff thing?

I think this sounds kinda exciting.  :-)  If it's feasible in practice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no