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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> "minor" is your judgement.
>
> You could try making a case for it not being minor, maybe you will be
> able to convince.  For now, I don't see how it could be anything but
> minor, or else we would have changed it long ago.

See this bug report and its duplicateds. It is not a data-loss bug, but
something that can be a constant annoyance to some users.

It occurred to me at least two times to use M-q on comments on some C++
header, see no changes, proceed with other edits elsewhere on the
project, and much later do `C-x s ! M-x compile' and see how the build
compiled files that shouldn't be affected by my edits, which, apart from
the waste of time on the extended build, caused more time to be wasted
on investigating the cause. Since I aware of the problem, if I use M-q
on a source file, I need to use `C-x s d' to see a diff and, if the diff
is empty, use undo to restore the modified flag.

>> And so far there is zero evidence that this change could cause
>> undesired effects.
>
> That's irrelevant.  It would be irresponsible for us to change such
> basic aspects of Emacs operation at this point in Emacs history.  We
> have been burnt with much less significant backward-incompatible
> changes.

This is a recipe for changing *nothing* that is older than some
threshold, isn't it? And we are talking about fill-paragraph here, not
about some core data structure. Apart from the fact that marking the
buffer as modified when text properties are changed is wrong in
principle (otherwise, why don't mark as modified the file-visiting
buffers as soon as some text properties are applied when the major/minor
modes are enabled?)

[snip]