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: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: 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 12:39:17 +0100

On 22.03.2016 11:50, Jaakov wrote:
> 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.)
>
>
>

IMHO fill-paragraph deserves a clean-up, a complete re-write. Initial 
relying at return-values of or-clause looks error-prone.

Previous Next

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