GNU bug report logs - #13949
24.3.50; `fill-paragraph' should not always put the buffer as modified

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 13949 <at> debbugs.gnu.org
Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified
Date: Sun, 27 Mar 2016 20:51:35 +0300

> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Cc: 13949 <at> debbugs.gnu.org
> Date: Sun, 27 Mar 2016 19:30:36 +0200
> 
> 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.

You are describing what I consider to be a minor annoyance.  I agree
it's an annoyance, and I agree it would be good to have an option to
prevent that, I'm just saying the annoyance is minor.

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

No, only those aspects that are very basic, like text properties being
an integral part of buffer text.

> And we are talking about fill-paragraph here, not about some core
> data structure.

I wasn't talking about fill-paragraph, I was talking about deciding
that changes in text properties aren't considered buffer
modifications.

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

I think you are only considering face properties.  But text properties
can be something entirely different.  I gave 2 examples before, here's
another, perhaps more relevant one: the 'fill-space' and 'hard'
properties that are directly involved in text filling.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.