found 13949 24.4.1
severity 13949 normal
thanks
Dani said:
> fill-paragraph first removes all the newlines from the paragraph, and
> then inserts only as many as needed to get a filled paragraph. So the
> buffer gets changed at least twice in the process.
This is _how_ it is done, not _what_ is done. Then "what" is described
in the documentation
https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Modification.html
:
"Emacs keeps a flag called the modified flag for each buffer, to
record whether you have changed the text of the buffer. This flag is
set to t whenever you alter the contents of the buffer, and cleared to
nil when you save it."
The description of fill-paragraph at
http://www.gnu.org/software/emacs/manual/html_node/emacs/Fill-Commands.html
mentions no exception to the above and "Emacs always behaved like
that" is just saying that the issue is old.
Since fill-paragraph does not heed the above piece of
"modified"-flag--documentation, it represents a non-compliance with
the (informal) specification, i.e., a typical bug.
Therefore, I changed the severity from wishlist to normal.
There are two ways to deal with it: to repair fill-paragraph or to
repair the documentation.
(A non-related personal aside: since recently, I had to rely both on
the star in the left lower corner /which means modified/ and paragraph
filling quite a lot. So the issue really, really bothers me. Of
course, nobody is forced to repair it if it is just extremely hard to
do. We are all busy. But I would be extremely happy to see the
fill-paragraph repaired, at least for text-mode and latex-mode
with/without installed auctex, if it makes any difference.
Btw., I tend to think that hash computing like sha1 could potentially
lead to rare, hard-to-reproduce hash clashes, where the text has
changed, but the sha1 says that the text is the same. If so,
implementing hash-checking would be worse that the current situation.)