From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Mon, 28 Mar 2016 00:20:08 +0300 Message-ID: <343192e9-ea13-21fa-45be-b2d1737bedb7@yandex.ru> 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> <9d1fed3c-fdcb-dfe3-e04d-47680d3e0531@yandex.ru> <87egawaq84.fsf@wanadoo.es> <5ae788d4-42cc-e1f9-dfa4-c25ff2acc10f@yandex.ru> <6d4fb517-8fc7-6d8f-afce-9387e509a46c@yandex.ru> <87shzb8wd5.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1459113682 2198 80.91.229.3 (27 Mar 2016 21:21:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 21:21:22 +0000 (UTC) Cc: John Wiegley , Lars Magne Ingebrigtsen , 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 23:21:11 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 1akI7S-0003jQ-Js for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Mar 2016 23:21:10 +0200 Original-Received: from localhost ([::1]:37459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akI7R-000843-KW for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Mar 2016 17:21:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akI7O-00083u-Ak for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 17:21:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akI7K-0001Jr-A3 for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 17:21:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akI7K-0001Jm-5l for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 17:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1akI7J-0005qO-Vk for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 17:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Mar 2016 21:21: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.145911361822389 (code B ref 13949); Sun, 27 Mar 2016 21:21:01 +0000 Original-Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 21:20:18 +0000 Original-Received: from localhost ([127.0.0.1]:40458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akI6c-0005p0-8F for submit@debbugs.gnu.org; Sun, 27 Mar 2016 17:20:18 -0400 Original-Received: from mail-wm0-f44.google.com ([74.125.82.44]:37921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akI6a-0005ol-LR for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 17:20:17 -0400 Original-Received: by mail-wm0-f44.google.com with SMTP id l68so78501188wml.1 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 14:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=eVT2Iddtgjem45OPwgHjZLRFivU5s4qAjUusgluQZlA=; b=xZgRuP1+b2QyCreBzQU0bpFcmfBe4sB459Et2rlpcByD/Aie1IQ4SbEcktBW3RRBKK dGakHU3ML2vGMjqsz5mtsWgpRcxiwrAckNOwKejCJItp8Ofb3lo20eWrVY1S9LMbBvz9 0ROP8BW2Iq96RlMcjP/sTkaJL5JYaL2d1Wunrd60trJU4TuQ5rfc7IXgdbkBCLp0NtkZ dN/qslLkNbSkSfYPFrvJVaBiAIbKBoEc0hciIAstyqhOOyrc8Dng3JP9zVeudnCglwL7 lk16YsCpF85pdY8xK9OUUSNiSMGuN5t+EBT93rLeJdFVfR9HrAplKZPCs+CCYAxpyNWQ gb8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eVT2Iddtgjem45OPwgHjZLRFivU5s4qAjUusgluQZlA=; b=aiI5devt0MS3qeSFkqAMb7fZyZNkviT6PZyBSyOwG7PehMtPZUV4vnzrorgOgfLOeg lIT8GZWjZIK67Q59rUgYNf4f7RvN/4IFCerXxT2pJ94yxyxr7Qiz0qZcWOkQTUDGWXzT nonxd2zKgiDz1TJmZtH2n9eS/BhWoQSdQxWesTxXEurUaLIflZ2J+s6dt6XHtZ90YJSk wz5ol4M6b+LgkA/1vesbqFRYgpH7VbXqsLoK0hvIlO5vTtkQ68gRC43WFI6dyALuTzj1 1lCEm24h5ogjjMbX8vXbi2j+jCcymMoAfXMdHGhKcyVPz/jZeiTCme6aei1rGGJ9aexT 4ZUg== X-Gm-Message-State: AD7BkJKObYAnz3Y/sZBWVmwcXkwU1hSHj+AULsKkDbQYWiP5UZVTHCI4FS2LQoL+HSzg3g== X-Received: by 10.28.173.71 with SMTP id w68mr7789056wme.88.1459113611069; Sun, 27 Mar 2016 14:20:11 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id hq2sm21934206wjb.3.2016.03.27.14.20.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 14:20:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <87shzb8wd5.fsf@wanadoo.es> 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:115611 Archived-At: On 03/28/2016 12:05 AM, Óscar Fuentes wrote: > I guess that the extra bits of entropy (160 vs 128) was a "fuzzy-warm" > factor too on using SHA-1 instead of MD5. Git must avoid collisions > among potentially hundreds of millions of objects (repos with that size > already exists or will exist on the near future.) Are there fewer different texts we'd have to be able to discern? > Each and every hash > must be different from all the others and hence avoid the Birthday > Problem. Anyway, 128 bit hashes still would be good enough for those > huge repos. fill-paragraph needs to discriminate only between 2 chunks > of data. I think you mean "2 chunks of data that must only be different in positioning and presence of newlines". Then yes, the odds of a collision must be slim. Still, I haven't seen (or performed) a sufficient analysis to evaluate them. >> b) Git has a global object index. It _can_ detect collisions, or at >> least that detection can be implemented. > > And what to do when a collision is detected? Abort the current operation? Wait 50ms and retry creating the commit? Not 100% how the file contents are indexed: e.g. whether mtime factors into its hash value, too. > Back to the topic, your suggetion about comparing the pre- and post- > contents of the paragraph (and avoiding huge copies of the pre- contents > by restricting the copied area to the paragraph itself) does not work > when the file contains just one paragraph. Try visiting a big CSV dump > or log and press M-q. You can abort the operation with C-g, but if Emacs > starts to swap like crazy or exceeds the process memory limit and it is > killed... You can choose to skip the "did it changed" check if the region to check is too long. If the dump was one huge line, we can be confident that it will be changed upon filling.