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

[Drew Adams <drew.adams@oracle.com>]

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

Why do you think that?  Code that uses text properties does not
necessarily change other things in the buffer.  I see no connection
between the two.

The fact that you even added "unrelated to font-locking" is perhaps
a giveaway. Font-locking is the best known use of text properties.
And even it does not typically involve changing other things in the
buffer.  Why would you expect that other code that uses text properties
would be different?  What's so special about font-locking in this regard?

If anything, I would expect other code that uses text properties
to _not_ change the buffer otherwise - just like font-lock.

I say "if anything", because I don't really think there is any
connection between using text properties and other buffer changes.

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

Why?  Where do you get 99%?  Or even 25%?  On what do you base the
assumption that code that uses text properties also makes other
buffer changes?  What do you see as the use cases of text properties,
of which 99% change the buffer otherwise?