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

[Jaakov <j_k_v@ro.ru>]

On 03/22/2016 05:15 PM, Eli Zaretskii wrote:
>> From: Jaakov <j_k_v@ro.ru>
>> Date: Tue, 22 Mar 2016 11:50:08 +0100
>>
>>> 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.
>
> I disagree.  I think Dani is right: the buffer text is changed (at
> least twice), which turns on the modified flag.  This situation is
> equivalent to inserting a character and then deleting it: the buffer
> stays modified, although its text is identical to the original one.
>
Objection for the following reason:
- It's a human who types in and deletes a charter.
- fill-paragraph is not a human, but a routine.

A routine is allowed to do all kinds of strange stuff, e.g., to split a 
long line it into chunks such that each chunk fits into a memory-page, 
process the chunks separately, then recombine the results, inserting, 
deleting, and cutting on need. Or to store all the text lines compressed 
and run clever algorithms on the compressed representation. An ingenious 
(though probably currently nonexistant) LISP interpreter could take your 
implementation of fill-paragraph and automatically convert it into an 
equivalent, lazy routine which modifies each cell of the the buffer zero 
times or once---completely transparent to you as the programmer. 
Probably, the user cannot and should not be aware of any such details.

Was I clear on the distinction of
(1) what is done by a command and
(2) how it is done
?

In my view, changing the buffer twice is an implementation decision (2) 
of fill-paragraph, not a specification/documentation decision (1). In my 
view, the modifies-flag, or, at least, the star in the left lower 
corner, also refers to (1).

If one does nevertheless represent the viewpoint that this 
implementation detail (rewriting the buffer twice) is important and 
should be user-visible, one should probably rewrite the documentation of 
fill-paragraph to reflect this issue.

If one represents the viewpoint that the modifies flag should reflect 
the internal implementation, one should probably implement the 
user-visible buffer-modification in some other way than reading 
modifies-flag. And document it properly.