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

Previous Next

Full log

Message #63 received at 13949 <at> debbugs.gnu.org (full text, mbox):

From: Jaakov <j_k_v <at> ro.ru>
To: control <at> debbugs.gnu.org, 13949 <at> debbugs.gnu.org
Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer
 as modified
Date: Tue, 22 Mar 2016 11:50:08 +0100

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

Previous Next

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