From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jaakov Newsgroups: gmane.emacs.bugs Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Tue, 22 Mar 2016 18:40:13 +0100 Message-ID: <56F1837D.4060300@ro.ru> References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1458668499 4194 80.91.229.3 (22 Mar 2016 17:41:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Mar 2016 17:41:39 +0000 (UTC) Cc: 13949@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 22 18:41:24 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aiQIq-0001ol-9g for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Mar 2016 18:41:12 +0100 Original-Received: from localhost ([::1]:38639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiQIp-0003UI-On for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Mar 2016 13:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiQIl-0003Ts-5g for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 13:41:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiQIg-0006sJ-1x for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 13:41:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiQIf-0006sC-Ug for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 13:41:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aiQIf-0003zH-Py for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 13:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jaakov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Mar 2016 17:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13949 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13949-submit@debbugs.gnu.org id=B13949.145866841915264 (code B ref 13949); Tue, 22 Mar 2016 17:41:01 +0000 Original-Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 17:40:19 +0000 Original-Received: from localhost ([127.0.0.1]:60276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQHy-0003y8-Kz for submit@debbugs.gnu.org; Tue, 22 Mar 2016 13:40:18 -0400 Original-Received: from huan1.mail.rambler.ru ([81.19.66.27]:8563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQHw-0003xw-7s for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 13:40:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ro.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=SaM1vriL9XUqPHrXV717zNbawPpwS35aRrngQK53jC0=; b=OMeI6baRbbysTvf9MDiV2mFTRQ59aDs6q/f9S4vwlh0uCw2I2QqTCyeO3MAuMs2gfELQvnU1lLiwAQUSgi2pzJhzO+pVFOJ6JUNj5x/BJEIfyRvPaiBYUfSx7ROaDW2TEvdh4JhMSlo16HfYsx2vJivbKpFlUxkmr9FsIfMHLnk=; Original-Received: from [UNAVAILABLE] ([131.159.50.38]:3409) by huan1.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiQHu-00059D-05; Tue, 22 Mar 2016 20:40:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 In-Reply-To: <83y49a4hga.fsf@gnu.org> X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115339 Archived-At: On 03/22/2016 05:15 PM, Eli Zaretskii wrote: >> From: Jaakov >> 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.