From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Sun, 27 Mar 2016 18:58:21 +0200 Message-ID: References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> <56F19203.5040501@ro.ru> <87a8lkd2bc.fsf@wanadoo.es> <83lh54ynol.fsf@gnu.org> <87mvpkaqj9.fsf@wanadoo.es> <37404e91-f1bf-072c-ff05-a3070391003e@yandex.ru> <87a8ljc3zx.fsf@wanadoo.es> <87vb47ao2k.fsf@wanadoo.es> <87io07amxo.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1459097962 3799 80.91.229.3 (27 Mar 2016 16:59:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 16:59:22 +0000 (UTC) Cc: 13949@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 27 18:59:10 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 1akE1t-0002W0-Rx for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Mar 2016 18:59:10 +0200 Original-Received: from localhost ([::1]:36725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akE1s-0001jX-Sf for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Mar 2016 12:59:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akE1p-0001jO-M3 for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:59:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akE1m-00018v-En for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:59:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akE1m-00018r-Am for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1akE1m-0007vR-3C for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Magne Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Mar 2016 16:59:02 +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.145909790930423 (code B ref 13949); Sun, 27 Mar 2016 16:59:02 +0000 Original-Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:58:29 +0000 Original-Received: from localhost ([127.0.0.1]:40364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akE1F-0007uc-6L for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:58:29 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:33770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akE1C-0007uU-MA for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:58:28 -0400 Original-Received: from cm-84.215.1.64.getinternet.no ([84.215.1.64] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1akE17-0003HT-MF; Sun, 27 Mar 2016 18:58:25 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX++/xdBxiLIC4HAQQS AggyBA92Ch3qvsO0vvdGAAACW0lEQVQ4jX2TQW/jIBCFueU8bqBno+34XEF+QBbonkkhPYPW9Br5 EP/9fTiRWu2260OQ5pv35nlMxKP45nkUl6/KO/G4+xJAsX5n9Y1A/Gf4v4Nhcvka7C5/gd26rlov U9d8BgtXfXumD8VumdblXm6l6TvYoXaBTYOk6dLUDey21nU8LY01Vy5EDStZ77aa84R2zVyiUmJg UgN3UDnX3tTaHKEgIqnQV5faMk0wokixNSEpy9i4VW6N5HAd+gRqJEhRpljUxKByWAg8UqWuyFnN qqdpMq48tkLcrfYhS4xZStWYOo1MhUpjQVIGSbHqgrHzcUJYpO2pcsoYUq+lNVjhbUqhQQEkD69z 5X3TTMirqBQsS0jrPYDmvUJQ2WdENfThPoSQouZ0hEd6H2uh/lIAsMrDwv4FM/ZVQ9jXImTwOcf3 hcNRs5TIjAUVdVP48wSFPTGkfbl1xIeSBrHUuozJPBe4Tlemisxd4W0+aZ38y5Oxebg2Yu7AeQT+ uaBBsTX+Teu51T7cGOutfjDmUDlZH35pajzUDox9dvg9cPttnT/SOMxqUxjjzQYGaZyxYYiycgfB vHZga5XWGRdOsY3UgfcbMOf6AIU7BC5PEakg3uqY/tSFwZdckpDJHu7ADD/6vJBUIFyGZEK61e3B bYc/v8wBwOU7eL4dPsTz7IXMPt7Brd26FGQCkFkl/6mO3YW9M/2Kluw+gANIyXZQx/xqLGo34Kzt jSIWLnPvA3CbU6cdqKLm7FMOIRuLuoOyg0z4+rh0KgQyWK69JxH4j+iCaDknv0XCATvzB0Ti2BJm 2Fl0AAAAAElFTkSuQmCC In-Reply-To: <87io07amxo.fsf@wanadoo.es> ("=?UTF-8?Q?=C3=93scar?= Fuentes"'s message of "Sun, 27 Mar 2016 18:46:27 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) 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:115595 Archived-At: =D3scar Fuentes writes: >>> I don't think so. It could be auto-disabled for large buffers and the >>> check would only take place when the size of the buffer is the same as >>> the size of the original file. >> >> Oh yeah, that's true... Except for the problem with the text >> properties. :-) > > Oh yes, apparently the fix for this bug must be bug-compatible with the > feature it is fixing. :-) But, come to think of it, I think it's quite rare in practice to do a lot of text property related editing without changing the size of the buffer, so perhaps this doesn't matter much. I mean, if you have a work flow that involves you opening a 2GB file, and then placing text properties (unrelated to font-locking) all over the place without changing the buffer otherwise, then... you're probably kinda unusual? So the "only hash when the buffer size is the same as when you loaded the file" thing would probably avoid the hashing in more than 99% of the use cases. >> I think I'd want the "buffer changed" indicator to reflect the state >> immediately after doing an edit, though. It's been a long-standing >> annoyance that Emacs claims that the buffer is changed when it "kinda >> isn't" (i.e., insert "a" and then delete it). I want to see that >> immediately in the mode line. > > Agreed. As long as the file is small enough for the hash function, an > idle timer with a short span would do. We don't want the hashing running > again and again while some command does multiple changes to the buffer. But I really think it has to be immediate and predictable for Emacs to keep working as it does. I mean (progn (find-file "~/foo") (insert "zot") (save-buffer)) must work reliably. One argument against switching to hash based edition detection is that we'd have a different method of computing the change when we have a buffer visiting a file and not... or... perhaps not? `(set-buffer-modified-p nil)' could be the function that computes the "initial" hash'n'size that would be used later, and `buffer-modified-p' could just compare with that tuple... This would allow us to get rid of the... er... thing that keeps track of buffer modification now... is that the text->modiff thing? I think this sounds kinda exciting. :-) If it's feasible in practice. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no