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

[John Wiegley <jwiegley@gmail.com>]

severity 13949 wishlist
thanks

>>>>> Jaakov  <j_k_v@ro.ru> writes:

> I don't consider the previous argument for disagreement valid for the
> mentioned reasons.

Hi Jaakov,

Eli does not have to convince you of anything: If he wants to work on a bug,
he will; if he doesn't, he won't. Setting the priority does not determine what
our developers decide to work on, it only serves as a general classification.
So you are welcome to express your thoughts on the relevance of a bug, but
there is no cause for argument; also, please stop adjusting bug priorities.

As to your point, I like the distinction you're making.  In fact, one could
imagine a guarding form that could be used by functions like `fill-paragraph':

  (modified-only-if-changed
    FORM)

This would save the current buffer-modification flag, and perform some check
at the end to verify changes were actually made before allowing it to be set
(such as checking the textual content of a filled region for real textual
modifications).

However, while great intellectually, this does have it downsides:

  1. The complexity of our code is increased for a problem that is not severe.
  2. There is a performance cost, especially if the fill region is huge.

So we must ask ourselves: What will fixing this issue actually solve? We'd no
longer modify timestamps when unnecessary, and the user wouldn't feel
compelled to save at times when it is not needed. That is all I can think of.
Therefore, this bug is truly a wishlist item.

I've noticed over the past couple of decades that M-q always sets my modified
flag. It never once occurred to me that this should be considered a problem.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2