From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 13 18:10:58 2013 Received: (at submit) by debbugs.gnu.org; 13 Mar 2013 22:10:58 +0000 Received: from localhost ([127.0.0.1]:52037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFtsv-0003Uz-3j for submit@debbugs.gnu.org; Wed, 13 Mar 2013 18:10:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54582) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFtss-0003Um-9Z for submit@debbugs.gnu.org; Wed, 13 Mar 2013 18:10:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFtrg-0003fh-9z for submit@debbugs.gnu.org; Wed, 13 Mar 2013 18:09:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:52083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFtrg-0003fO-6z for submit@debbugs.gnu.org; Wed, 13 Mar 2013 18:09:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFtrf-0000U1-4D for bug-gnu-emacs@gnu.org; Wed, 13 Mar 2013 18:09:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFtrd-0003bI-RT for bug-gnu-emacs@gnu.org; Wed, 13 Mar 2013 18:09:39 -0400 Received: from mail-la0-x22e.google.com ([2a00:1450:4010:c03::22e]:63483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFtrd-0003YO-HQ for bug-gnu-emacs@gnu.org; Wed, 13 Mar 2013 18:09:37 -0400 Received: by mail-la0-f46.google.com with SMTP id fq12so1743118lab.19 for ; Wed, 13 Mar 2013 15:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=7cosPOeS9Qdn1SnP7yeQV8DPgH39d/1KDMqBUjlhWy4=; b=qmRQFzSabhA8ZOU0uzEIBZku32CJgJVmUyOaCNQh6ydp2dI5n7Tyh9WVS31kaiP4DH dWTRuOrZ4vH73SvHMAEGOb7+NHEcU34gcwsoeXUDbatm51m1osG/y5/D03OTkxD3Vsdg cNEsj6/+EI0P/juYrt5pLuDoUnbk49Kg43+62ouuyrLWoxldUHpmDyA7UnHnHmbsk6/b DzNHLrVu6oboERHWKidZE7P44Q29NdQ+lMmkFV79lGSFs0p7+sB0uVMyZ9PRnoPfIbH8 uIGNHTJk4frOBfv3BGwxqyqTwbyGG5S7hVWGVkhXad/x5e6GLuwm7GryNIpUlhpHiUmB 7GEA== MIME-Version: 1.0 X-Received: by 10.152.104.18 with SMTP id ga18mr19215540lab.33.1363212575696; Wed, 13 Mar 2013 15:09:35 -0700 (PDT) Received: by 10.114.29.137 with HTTP; Wed, 13 Mar 2013 15:09:35 -0700 (PDT) Date: Wed, 13 Mar 2013 23:09:35 +0100 Message-ID: Subject: 24.3.50; `fill-paragraph' should not always put the buffer as modified From: Dani Moncayo To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Recipe from "emacs -Q": 1. Visit some plain text file. 2. Move point to some paragraph with more that one line. 3. M-q C-x C-s 4. M-q After step #3, the buffer is not modified wrt its file (you've just save it), but step #4 puts the buffer in a modified state ("**" flag in the modeline). This seems a bug, since step #4 didn't make any change in the buffer contents (the paragraph was already filled). In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.13) of 2013-03-13 on LEG570 Bzr revision: 112040 kfogel@red-bean.com-20130313185405-ibq2um8vj55d4x0a Windowing system distributor `The X.Org Foundation', version 11.0.11300000 System Description: Ubuntu 12.10 -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 13 23:44:32 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 03:44:32 +0000 Received: from localhost ([127.0.0.1]:52312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFz5k-00030A-FA for submit@debbugs.gnu.org; Wed, 13 Mar 2013 23:44:32 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:59596) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFz5h-0002zu-Vr for 13949@debbugs.gnu.org; Wed, 13 Mar 2013 23:44:31 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MJM00C00SUCNQ00@a-mtaout23.012.net.il> for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 05:43:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJM00CDET01NL20@a-mtaout23.012.net.il>; Thu, 14 Mar 2013 05:43:13 +0200 (IST) Date: Thu, 14 Mar 2013 05:43:13 +0200 From: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <83li9qir3i.fsf@gnu.org> References: X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 13 Mar 2013 23:09:35 +0100 > From: Dani Moncayo > > 1. Visit some plain text file. > 2. Move point to some paragraph with more that one line. > 3. M-q C-x C-s > 4. M-q > > After step #3, the buffer is not modified wrt its file (you've just > save it), but step #4 puts the buffer in a modified state ("**" flag > in the modeline). > > This seems a bug, since step #4 didn't make any change in the buffer > contents (the paragraph was already filled). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4946] X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Wed, 13 Mar 2013 23:09:35 +0100 > From: Dani Moncayo > > 1. Visit some plain text file. > 2. Move point to some paragraph with more that one line. > 3. M-q C-x C-s > 4. M-q > > After step #3, the buffer is not modified wrt its file (you've just > save it), but step #4 puts the buffer in a modified state ("**" flag > in the modeline). > > This seems a bug, since step #4 didn't make any change in the buffer > contents (the paragraph was already filled). Step #4 does change the buffer, because M-q doesn't know whether the paragraph is already filled, so it fills it anew each time. Emacs always behaved like that. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 03:58:58 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 07:58:58 +0000 Received: from localhost ([127.0.0.1]:52670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG33w-0000Un-Hz for submit@debbugs.gnu.org; Thu, 14 Mar 2013 03:58:57 -0400 Received: from mail-la0-f48.google.com ([209.85.215.48]:56773) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG33t-0000Ua-LG for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 03:58:54 -0400 Received: by mail-la0-f48.google.com with SMTP id fq13so2073798lab.21 for <13949@debbugs.gnu.org>; Thu, 14 Mar 2013 00:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TzKlqvw09lDy22vqgs5La0q6PoeNCM8py9oAgQO8HSc=; b=PkR5aFpCN8j4EkbfwFki+rmarf8HFtS59EODuHAUOR2bh5ri/UQxbUzP3BFRYK6Svx jBl/LQdmJKLhQK5klAMappQ+aNQZN1ASEIhBQVyoWG6BVsHtzxV3+n40tZtl2kVuMUJy YSJU5pOn4MMdTB0Ec0CWPYq5VYDrLcNjVtWgk4OE+9v2feRB5uCKN8RUAJ03YyRq6htI AdGQ3wQS+RPK2Kn7ilFJY+ZvtghV3ywgDlJuuXfoWSLrT5TxKx36c7drsltpL/XuDeIj 2sF7jIXyv1kA31Safn7zummUZerQzojFH8Mp96oOxDabrCSL0YodomB5cCi7Qi+vw5G/ 70Pw== MIME-Version: 1.0 X-Received: by 10.152.104.199 with SMTP id gg7mr1260377lab.14.1363247855924; Thu, 14 Mar 2013 00:57:35 -0700 (PDT) Received: by 10.114.29.137 with HTTP; Thu, 14 Mar 2013 00:57:35 -0700 (PDT) In-Reply-To: <83li9qir3i.fsf@gnu.org> References: <83li9qir3i.fsf@gnu.org> Date: Thu, 14 Mar 2013 08:57:35 +0100 Message-ID: Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified From: Dani Moncayo To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) >> This seems a bug, since step #4 didn't make any change in the buffer >> contents (the paragraph was already filled). > > Step #4 does change the buffer, because M-q doesn't know whether the > paragraph is already filled, so it fills it anew each time. > > Emacs always behaved like that. Ah, Ok. Well, since the `fill-paragraph' command at step #4 leaved the buffer with the same contents, flagging the buffer as modified was unnecessary in this case. In general, I think that a command should flag the buffer as modified only when the buffer contents at the end of the command were different from the contents at the beginning of that same command. But, I don't know complex is that to implement, and perhaps that complexity outweighs the benefits. I'll let you (maintainers) to judge this. Feel free to close this bug if the change isn't worth the trouble. Thanks. -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 06:28:03 2013 Received: (at submit) by debbugs.gnu.org; 14 Mar 2013 10:28:03 +0000 Received: from localhost ([127.0.0.1]:52882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG5OD-0003yZ-UM for submit@debbugs.gnu.org; Thu, 14 Mar 2013 06:28:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46281) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG5OB-0003y4-Vw for submit@debbugs.gnu.org; Thu, 14 Mar 2013 06:28:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG5Mw-0005zG-L3 for submit@debbugs.gnu.org; Thu, 14 Mar 2013 06:26:44 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:45483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG5Mw-0005zC-J8 for submit@debbugs.gnu.org; Thu, 14 Mar 2013 06:26:42 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG5Ms-0003cO-22 for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 06:26:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UG5Mn-0005xb-Ut for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 06:26:37 -0400 Received: from moutng.kundenserver.de ([212.227.17.8]:57001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UG5Mn-0005xV-LQ for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 06:26:33 -0400 Received: from [192.168.178.21] (brln-4d0c1994.pool.mediaWays.net [77.12.25.148]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lmufk-1UwrlU0suq-00h2qK; Thu, 14 Mar 2013 11:26:32 +0100 Message-ID: <5141A60D.7030707@easy-emacs.de> Date: Thu, 14 Mar 2013 11:27:25 +0100 From: =?ISO-8859-1?Q?Andreas_R=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified References: <83li9qir3i.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:GWopmONpAg8QjauEiirpgsIhPLRPtqsdpViugNftOTH 0DLIQsu8NPnVr0SZCRjqo5ZC2Ji3X6oWVbXZStztLleUCOgseI zURWZVT93b8ga9VUsLl8n3biy9BD1egMvlAf2vqAbQ+FT55ovy Jfeymy9PC7rS0HR2mcgInwGVxQPTyT3y2QzA3fwXxIDYyiw+Q4 K/xIAj7DsKOOz5A0v8KBrVgLqZWkgUBoAQlDuJvff76xOY4+FE Oh32uPvishmW3IRxhxSIeOm7vsJEXsHp4xVzz5eCHWfy9+2gGx /LoIMOmdOyMwobPyMpVVB2vzETELw4fUfTT5G/w+0ODbwsz3wp 80As2WmlEEVAEilti+ZIAj2WcZ++A9Vjf/ZFVDi+Z X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Am 14.03.2013 08:57, schrieb Dani Moncayo: >>> This seems a bug, since step #4 didn't make any change in the buffer >>> contents (the paragraph was already filled). >> >> Step #4 does change the buffer, because M-q doesn't know whether the >> paragraph is already filled, so it fills it anew each time. >> >> Emacs always behaved like that. > > Ah, Ok. > > Well, since the `fill-paragraph' command at step #4 leaved the buffer > with the same contents, flagging the buffer as modified was > unnecessary in this case. > > In general, I think that a command should flag the buffer as modified > only when the buffer contents at the end of the command were different > from the contents at the beginning of that same command. > > But, I don't know complex is that to implement, and perhaps that > complexity outweighs the benefits. Hi, don't think it's complex. AFAIU the changed-flag presently is set by some commands assumed to change the buffer without regard to the result - as shown. Should not be that complicated to copy the buffers contents into a temporary buffer in this case and check both buffers afterwards if being equal. IMHO it's worth to do that change wrt fill-commands. Best, Andreas > > I'll let you (maintainers) to judge this. Feel free to close this bug > if the change isn't worth the trouble. > > Thanks. > From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 09:39:28 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 13:39:28 +0000 Received: from localhost ([127.0.0.1]:53238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG8NS-00012p-V8 for submit@debbugs.gnu.org; Thu, 14 Mar 2013 09:39:27 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:38619) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UG8NR-00012c-Lt for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 09:39:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KL9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av8EABK/CFHO+KL9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="4897437" Received: from 206-248-162-253.dsl.teksavvy.com (HELO pastel.home) ([206.248.162.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 14 Mar 2013 09:38:07 -0400 Received: by pastel.home (Postfix, from userid 20848) id 51E0E67A4D; Thu, 14 Mar 2013 09:38:08 -0400 (EDT) From: Stefan Monnier To: Dani Moncayo Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified Message-ID: References: <83li9qir3i.fsf@gnu.org> Date: Thu, 14 Mar 2013 09:38:08 -0400 In-Reply-To: (Dani Moncayo's message of "Thu, 14 Mar 2013 08:57:35 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: Eli Zaretskii , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Well, since the `fill-paragraph' command at step #4 leaved the buffer > with the same contents, flagging the buffer as modified was > unnecessary in this case. AFAIK there are two ways to go about it: - compare the sha1 of the paragraph before and after filling and reset buffer-modified-p if it shows the text hasn't changed. - change fill.el so that filling paragraph doesn't just "unfill whole paragraph + fill whole paragraph" but instead goes line by line, and only modifies the text where there's a need to. The second option has the advantage that it truly doesn't modify the buffer (hence, less font-lock work, less redisplay work, and also text-properties, overlays and markers aren't affected, contrary to the current behavior), but it requires more coding effort. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 13:48:04 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 17:48:05 +0000 Received: from localhost ([127.0.0.1]:54486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCG4-0001M5-H6 for submit@debbugs.gnu.org; Thu, 14 Mar 2013 13:48:04 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:41278) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCG2-0001Lc-Hy for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 13:48:03 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MJN00H00W0JLZ00@a-mtaout23.012.net.il> for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 19:46:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJN00HKQW1RG490@a-mtaout23.012.net.il>; Thu, 14 Mar 2013 19:46:40 +0200 (IST) Date: Thu, 14 Mar 2013 19:46:41 +0200 From: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified In-reply-to: X-012-Sender: halo1@inter.net.il To: Dani Moncayo Message-id: <83ehfhj2m6.fsf@gnu.org> References: <83li9qir3i.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > Date: Thu, 14 Mar 2013 08:57:35 +0100 > From: Dani Moncayo > Cc: 13949@debbugs.gnu.org > > In general, I think that a command should flag the buffer as modified > only when the buffer contents at the end of the command were different > from the contents at the beginning of that same command. Then your wish is much broader than the original bug report says. E.g., you'd like the following to leave the buffer marked as unmodified, right? emacs -Q M-< C-d ; Or how about this: emacs -Q M-x overwrite-mode RET M-< ; 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. > But, I don't know complex is that to implement, and perhaps that > complexity outweighs the benefits. Stefan answered that. I'll write there why I think it might not be a good idea. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 13:51:57 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 17:51:57 +0000 Received: from localhost ([127.0.0.1]:54496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCJl-0001RX-88 for submit@debbugs.gnu.org; Thu, 14 Mar 2013 13:51:57 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:63725) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCJf-0001RF-C2 for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 13:51:51 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MJN00E00W4R7U00@a-mtaout21.012.net.il> for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 19:50:28 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJN00EQWW847N10@a-mtaout21.012.net.il>; Thu, 14 Mar 2013 19:50:28 +0200 (IST) Date: Thu, 14 Mar 2013 19:50:30 +0200 From: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified In-reply-to: <5141A60D.7030707@easy-emacs.de> To: Andreas =?iso-8859-1?Q?R=F6hler?= Message-id: <83d2v1j2ft.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83li9qir3i.fsf@gnu.org> <5141A60D.7030707@easy-emacs.de> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Thu, 14 Mar 2013 11:27:25 +0100 > From: Andreas R=F6hler >=20 > AFAIU the changed-flag presently is set by some commands assumed to= change > the buffer without regard to the result - as shown. The flag is set by functions that are about to insert, delete, or replace portions of a buffer. > Should not be that complicated to copy the buffers contents into a = temporary buffer in this case > and check both buffers afterwards if being equal. >=20 > IMHO it's worth to do that change wrt fill-commands. IMNSHO, this doesn't make sense. E.g., what if the buffer is very large, and there won't be enough memory to have another copy of it? Even if it is not that large, why move large amounts of data in this case? Emacs uses the gap buffer paradigm precisely to avoid this kind of lossage. It doesn't make sense to throw that out the window for the benefit of a minor improvement. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 13:55:03 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 17:55:03 +0000 Received: from localhost ([127.0.0.1]:54501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCMo-0001WL-Li for submit@debbugs.gnu.org; Thu, 14 Mar 2013 13:55:03 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:42842) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCMl-0001Vo-UH for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 13:55:01 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MJN00G00W8I2J00@a-mtaout22.012.net.il> for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 19:53:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJN00GEAWDF2Z00@a-mtaout22.012.net.il>; Thu, 14 Mar 2013 19:53:39 +0200 (IST) Date: Thu, 14 Mar 2013 19:53:41 +0200 From: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83boalj2ai.fsf@gnu.org> References: <83li9qir3i.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org, dmoncayo@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Eli Zaretskii , 13949@debbugs.gnu.org > Date: Thu, 14 Mar 2013 09:38:08 -0400 > > > Well, since the `fill-paragraph' command at step #4 leaved the buffer > > with the same contents, flagging the buffer as modified was > > unnecessary in this case. > > AFAIK there are two ways to go about it: > - compare the sha1 of the paragraph before and after filling and reset > buffer-modified-p if it shows the text hasn't changed. This has the disadvantage of scanning the entire buffer, which might increase paging and memory pressure in general. > - change fill.el so that filling paragraph doesn't just "unfill whole > paragraph + fill whole paragraph" but instead goes line by line, and > only modifies the text where there's a need to. But it sounds like Dani wants this behavior not only for fill-paragraph, but for any command that can potentially modify the buffer, but actually doesn't. This would require to compute sha1 before and after every command that might change the buffer. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 14:35:17 2013 Received: (at submit) by debbugs.gnu.org; 14 Mar 2013 18:35:17 +0000 Received: from localhost ([127.0.0.1]:54561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCzk-0002TG-DC for submit@debbugs.gnu.org; Thu, 14 Mar 2013 14:35:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54078) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCzg-0002T0-MC for submit@debbugs.gnu.org; Thu, 14 Mar 2013 14:35:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGCyP-00028W-PB for submit@debbugs.gnu.org; Thu, 14 Mar 2013 14:33:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:55118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGCyP-00028R-MF for submit@debbugs.gnu.org; Thu, 14 Mar 2013 14:33:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGCyO-0006aa-9h for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 14:33:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGCyL-00026Y-Ed for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 14:33:52 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:49579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGCyL-000269-59 for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 14:33:49 -0400 Received: from [192.168.178.21] (brln-4d0c1994.pool.mediaWays.net [77.12.25.148]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Me0wT-1U6dHD45ID-00PdtR; Thu, 14 Mar 2013 19:33:47 +0100 Message-ID: <51421840.1070208@easy-emacs.de> Date: Thu, 14 Mar 2013 19:34:40 +0100 From: =?ISO-8859-15?Q?Andreas_R=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> In-Reply-To: <83boalj2ai.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:LUh3c8ualQp81XMnhOjxfYLOvjB0n/uZDcPkIw0jt9a S+eyrJgoQYGWuI6gQUQegkVl0GCqmkLxvbV3xlUNjhB+J2VIKf C9k/GdwWmCkMjUn9hz4WWP8aLHik3aPhicPSIsLIF9+dACX9wj cGNplKvLuAToMJTDg7gfAeYbKq7iN2C/Q9XUdPcykFsUp4ws4u jkBeqWt0+rGj3k/kuA97qwJyCpiN/Kc4vBGfkFWAzhqNDvXVJu F6jyd+TFu3yq9LbRIfISi0s4EqOhiZzDi/mKvmXN8Tm78sIYrY GF+QG5Ki7H/2GFhUZ1OwIz/jFcbY0NPKyjyWarKvZvKJdUHgz+ COEAqUhxtl2m6LHH3PWqqdV208O5QNFl4d7j5PK/Y X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Am 14.03.2013 18:53, schrieb Eli Zaretskii: >> From: Stefan Monnier >> Cc: Eli Zaretskii , 13949@debbugs.gnu.org >> Date: Thu, 14 Mar 2013 09:38:08 -0400 >> >>> Well, since the `fill-paragraph' command at step #4 leaved the buffer >>> with the same contents, flagging the buffer as modified was >>> unnecessary in this case. >> >> AFAIK there are two ways to go about it: >> - compare the sha1 of the paragraph before and after filling and reset >> buffer-modified-p if it shows the text hasn't changed. > > This has the disadvantage of scanning the entire buffer, which might > increase paging and memory pressure in general. > >> - change fill.el so that filling paragraph doesn't just "unfill whole >> paragraph + fill whole paragraph" but instead goes line by line, and >> only modifies the text where there's a need to. > > But it sounds like Dani wants this behavior not only for > fill-paragraph, but for any command that can potentially modify the > buffer, but actually doesn't. This would require to compute sha1 > before and after every command that might change the buffer. > > > > If fill-paragraph is at stake only, store paragraph in a string at beginning and compare the result should be enough to reset the modify flag if justified. Andreas From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 14:35:54 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 18:35:54 +0000 Received: from localhost ([127.0.0.1]:54564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGD0L-0002U7-Bl for submit@debbugs.gnu.org; Thu, 14 Mar 2013 14:35:54 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:64763) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGD0J-0002Ts-2m for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 14:35:51 -0400 Received: by mail-lb0-f180.google.com with SMTP id q12so2094753lbc.25 for <13949@debbugs.gnu.org>; Thu, 14 Mar 2013 11:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6loYWYTBj9Gpw0OtxD4ge3hhf3xbI5av8txWJ9V+0tQ=; b=sBE0TaPzpou1s84iWdeKrvBJBwp4czBqm35Nk7muwZHxGBYZZDwBZRs5YwqiFmQ4Ns B48bme2rf+IrB4LGX7vFNPLluSEpSmBfjetAYYAjMKJV9J9UFVhMugWM/2ytSNy5bkfR 6i0ETK99J9j0qYy0B98iLuzcjKMEvM2Uw32SyJvJlQ3Hx70C3PmkuRxm+cSUXFfiyEnN Q4fYKngWkiwsVHn7uQHJC366BOjHoHnacXSPaj0YyJ3mD91Z2NZxgfShVuhZ8TxW7pkr aMvqb8t7MeNv64FfeeQw3bJ87J3D3PHBJIVb4sjDIbAIO9uEzmDKTLyhvMHoH3O+e0b7 iA+Q== MIME-Version: 1.0 X-Received: by 10.152.145.134 with SMTP id su6mr3144443lab.35.1363286071827; Thu, 14 Mar 2013 11:34:31 -0700 (PDT) Received: by 10.114.29.137 with HTTP; Thu, 14 Mar 2013 11:34:31 -0700 (PDT) In-Reply-To: <83ehfhj2m6.fsf@gnu.org> References: <83li9qir3i.fsf@gnu.org> <83ehfhj2m6.fsf@gnu.org> Date: Thu, 14 Mar 2013 19:34:31 +0100 Message-ID: Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified From: Dani Moncayo To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) >> In general, I think that a command should flag the buffer as modified >> only when the buffer contents at the end of the command were different >> from the contents at the beginning of that same command. > > Then your wish is much broader than the original bug report says. > E.g., you'd like the following to leave the buffer marked as > unmodified, right? > > emacs -Q > M-< > C-d > ; > > Or how about this: > > emacs -Q > M-x overwrite-mode RET > M-< > ; These two examples are recipes for modifying the buffer with several different commands whose global effect is void. In principle, one could expect that the buffer be flagged as modified only when the current text is different from the text in the file. That makes sense, and I thought about that, but I agree with you that that behavior, while desirable, would imply a big impact in performance and memory consumption, which is not justified at all for such a small feature. The expected behavior I described above is not exactly this, though, because I put it in a command-by-command basis, but anyway, I think that even then the price to pay would be too high in many cases (one single command may modify a large portion of text, even the whole buffer). > 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. Yes I understood that. I think that a nicer algorithm would be not to modify the buffer unless the resulting text is going to be different to the current one. But if that would entail too much work, I suggest to spend your valuable energy in more important things :) -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 14:50:31 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 18:50:31 +0000 Received: from localhost ([127.0.0.1]:54581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDEV-0002rk-4z for submit@debbugs.gnu.org; Thu, 14 Mar 2013 14:50:31 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:47657) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDEP-0002rM-NE for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 14:50:29 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MJN00H00YRZWB00@a-mtaout23.012.net.il> for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 20:49:05 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJN00HY0YXSRJ90@a-mtaout23.012.net.il>; Thu, 14 Mar 2013 20:49:05 +0200 (IST) Date: Thu, 14 Mar 2013 20:49:06 +0200 From: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified In-reply-to: <51421840.1070208@easy-emacs.de> To: Andreas =?iso-8859-15?Q?R=F6hler?= Message-id: <83620tizq5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> <51421840.1070208@easy-emacs.de> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Thu, 14 Mar 2013 19:34:40 +0100 > From: Andreas R=F6hler >=20 > If fill-paragraph is at stake only, store paragraph in a string at = beginning and > compare the result should be enough to reset the modify flag if jus= tified. It is not uncommon to have very large buffers with a single paragraph. What you suggest is hardly memory-efficient. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 15:01:46 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 19:01:46 +0000 Received: from localhost ([127.0.0.1]:54613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDPK-00039O-Ry for submit@debbugs.gnu.org; Thu, 14 Mar 2013 15:01:44 -0400 Received: from moutng.kundenserver.de ([212.227.17.9]:57074) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDPH-000396-LV for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 15:01:41 -0400 Received: from [192.168.178.21] (brln-4d0c1994.pool.mediaWays.net [77.12.25.148]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M5tNd-1Ues141c9R-00yNpZ; Thu, 14 Mar 2013 20:00:19 +0100 Message-ID: <51421E79.7010502@easy-emacs.de> Date: Thu, 14 Mar 2013 20:01:13 +0100 From: =?ISO-8859-15?Q?Andreas_R=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> <51421840.1070208@easy-emacs.de> <83620tizq5.fsf@gnu.org> In-Reply-To: <83620tizq5.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:IEH7/GddGy3pgnX4QYifr7u8VFSy2+Nmh/sn8UQ110i Zr0fpQB86GMuKs0ThTM+ruoPZPVM9YHDv/xqzPl2X4/DkA47Y3 mu2tnvW/WRw/WROdWj9ZQiWBoDplml6ZmGgl5TkkOpQj9GQrBM cICynpYNCpEIlrm7gdcIWeWkbDicQ6h/8SMh2YzaUhCQ56rMTT SZzyJmRfbtQM7PKCqg9FhG/NBeCMrcVKCK6QAVLqj9nWhlqcYu f5RXwTTO23TtEjE+OOPYb54IupTWlkt0//n9LOM3FG9FrTN7FJ hf9aXYvjwXEutsjAO/+d9+IdSxTiDEksJsgsZSWp+N6aWjx69D cLkcoECTK7qN41IoMMDc4jpPhu4yOS4sjhaNshesr X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Am 14.03.2013 19:49, schrieb Eli Zaretskii: >> Date: Thu, 14 Mar 2013 19:34:40 +0100 >> From: Andreas Röhler >> >> If fill-paragraph is at stake only, store paragraph in a string at beginning and >> compare the result should be enough to reset the modify flag if justified. > > It is not uncommon to have very large buffers with a single > paragraph. What you suggest is hardly memory-efficient. > In this case, after checking the length, writing it to a temp-file might be an option. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 15:20:37 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 19:20:37 +0000 Received: from localhost ([127.0.0.1]:54640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDhc-0003aV-NE for submit@debbugs.gnu.org; Thu, 14 Mar 2013 15:20:37 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:42710) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDha-0003aG-1u for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 15:20:35 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MJO000000ATWI00@a-mtaout20.012.net.il> for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 21:19:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJO000BG0C2LKA0@a-mtaout20.012.net.il>; Thu, 14 Mar 2013 21:19:14 +0200 (IST) Date: Thu, 14 Mar 2013 21:19:16 +0200 From: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified In-reply-to: <51421E79.7010502@easy-emacs.de> To: Andreas =?iso-8859-15?Q?R=F6hler?= Message-id: <834ngdiybv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> <51421840.1070208@easy-emacs.de> <83620tizq5.fsf@gnu.org> <51421E79.7010502@easy-emacs.de> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Thu, 14 Mar 2013 20:01:13 +0100 > From: Andreas R=F6hler > CC: 13949@debbugs.gnu.org >=20 > Am 14.03.2013 19:49, schrieb Eli Zaretskii: > >> Date: Thu, 14 Mar 2013 19:34:40 +0100 > >> From: Andreas R=F6hler > >> > >> If fill-paragraph is at stake only, store paragraph in a string = at beginning and > >> compare the result should be enough to reset the modify flag if = justified. > > > > It is not uncommon to have very large buffers with a single > > paragraph. What you suggest is hardly memory-efficient. > > >=20 > In this case, after checking the length, writing it to a temp-file = might be an option. April 1 is still way too far away to enjoy this. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 14 15:32:45 2013 Received: (at 13949) by debbugs.gnu.org; 14 Mar 2013 19:32:45 +0000 Received: from localhost ([127.0.0.1]:54657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDtM-0003sg-4U for submit@debbugs.gnu.org; Thu, 14 Mar 2013 15:32:45 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:58010) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDtJ-0003sT-FZ for 13949@debbugs.gnu.org; Thu, 14 Mar 2013 15:32:42 -0400 Received: from [192.168.178.21] (brln-4d0c1994.pool.mediaWays.net [77.12.25.148]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LrUzJ-1UkN310bkr-013QaX; Thu, 14 Mar 2013 20:31:22 +0100 Message-ID: <514225C0.9000104@easy-emacs.de> Date: Thu, 14 Mar 2013 20:32:16 +0100 From: =?ISO-8859-15?Q?Andreas_R=F6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> <51421840.1070208@easy-emacs.de> <83620tizq5.fsf@gnu.org> <51421E79.7010502@easy-emacs.de> <834ngdiybv.fsf@gnu.org> In-Reply-To: <834ngdiybv.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ks74O0odpdp3Pw2bZBVttM+awwzDl59c9VgZM3rhmHw AJQfSM1CojvOl6WYP9wasQv5wx57uQNq2vL0zgo4KB5VJWexgn GzmMWgYCRWMBVebZ7njqre7OipYBVWFbuD+RYjvPSzjdHmQXPm bTjBI2hb5mtmcuXtPRBJItvABI2e8v3IVClgEojCO7+FwWHaeP B0hFL10JyLhoUtKpwqwZrFOm592s/SmLx318buIfxFdWKfTHzp IW6KpsgMv67qru1d3avafQ7M2NJYcQi/JOo+Mm+o9WxXjTTog4 +Tld6dCb7AmuLK5Y/sbu4yaLLxCEyaz/B3M89Kj28k1+LckgLn s9lDuL0/R94bXw5BUXh77SdfSkUhh/WRr3IlFl+i/ X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > April 1 is still way too far away to enjoy this. > And until then let's invent the complicated, until even it's creator can't fiddle out the worm any more? From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 00:03:25 2013 Received: (at 13949) by debbugs.gnu.org; 15 Mar 2013 04:03:25 +0000 Received: from localhost ([127.0.0.1]:55215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGLrX-0007YF-K7 for submit@debbugs.gnu.org; Fri, 15 Mar 2013 00:03:24 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:2748) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGLrV-0007Y1-Gh for 13949@debbugs.gnu.org; Fri, 15 Mar 2013 00:03:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KL9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMQCzQSFBgNJIgeBsEtkQoDpHqBXoMT X-IPAS-Result: Av8EABK/CFHO+KL9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMQCzQSFBgNJIgeBsEtkQoDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="4961530" Received: from 206-248-162-253.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.162.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 15 Mar 2013 00:01:58 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 54D03AE0BC; Fri, 15 Mar 2013 00:02:00 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified Message-ID: References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> Date: Fri, 15 Mar 2013 00:02:00 -0400 In-Reply-To: <83boalj2ai.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Mar 2013 19:53:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org, dmoncayo@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> AFAIK there are two ways to go about it: >> - compare the sha1 of the paragraph before and after filling and reset >> buffer-modified-p if it shows the text hasn't changed. > This has the disadvantage of scanning the entire buffer, which might > increase paging and memory pressure in general. I think you can compute the sha1 of only the paragraph, so that should be cheap enough that it's not a big issue. >> - change fill.el so that filling paragraph doesn't just "unfill whole >> paragraph + fill whole paragraph" but instead goes line by line, and >> only modifies the text where there's a need to. > But it sounds like Dani wants this behavior not only for > fill-paragraph, but for any command that can potentially modify the > buffer, but actually doesn't. While I think he'd be happy if we could do that, I didn't take his request to be so extreme. So even if we can't handle all cases, it makes sense to try and improve this one case. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 15 03:29:26 2013 Received: (at 13949) by debbugs.gnu.org; 15 Mar 2013 07:29:26 +0000 Received: from localhost ([127.0.0.1]:55351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGP4t-0003qt-M5 for submit@debbugs.gnu.org; Fri, 15 Mar 2013 03:29:26 -0400 Received: from mail-la0-f53.google.com ([209.85.215.53]:40739) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGP4p-0003qg-Rz for 13949@debbugs.gnu.org; Fri, 15 Mar 2013 03:29:21 -0400 Received: by mail-la0-f53.google.com with SMTP id fr10so3371830lab.40 for <13949@debbugs.gnu.org>; Fri, 15 Mar 2013 00:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gs7GoZ3n0mPar6KdOF0x3cY2ZiVidzOKuLYthQG6f1s=; b=KtQVWjAPUskyzvenuTdthqmUaJrqwt/c/fCSDWxesUiN5zXM5lICIqy35Uw3C1dmpz ym/OOOyi+Y+WlHT1S4S/0n6QN7MnOTGurS7LLVXfqlcrEpwonUfTQig/+ZIY5nNM6uUS m1duBTbjQhh962jJenew1Drut62E42mA90/Lasnu62XOgioQ4/TSzRGhb01/A4ltoa45 PXJp0pXC+vcYSv7k5gk/KmJjtXAPapzdsFbLXbDFqR5tESKBYau0E0lghe6WCTH5RytN hJZdsWF9CNMdj/NKDY8icnBgcZ7MUZmK3DlHHRfk6OlyFqbPoENSc2yaBbGPkrOCYOyo aV+w== MIME-Version: 1.0 X-Received: by 10.112.54.6 with SMTP id f6mr2219626lbp.104.1363332478222; Fri, 15 Mar 2013 00:27:58 -0700 (PDT) Received: by 10.114.29.137 with HTTP; Fri, 15 Mar 2013 00:27:58 -0700 (PDT) In-Reply-To: References: <83li9qir3i.fsf@gnu.org> <83boalj2ai.fsf@gnu.org> Date: Fri, 15 Mar 2013 08:27:58 +0100 Message-ID: Subject: Re: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified From: Dani Moncayo To: Stefan Monnier Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13949 Cc: Eli Zaretskii , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) >>> - change fill.el so that filling paragraph doesn't just "unfill whole >>> paragraph + fill whole paragraph" but instead goes line by line, and >>> only modifies the text where there's a need to. >> But it sounds like Dani wants this behavior not only for >> fill-paragraph, but for any command that can potentially modify the >> buffer, but actually doesn't. > > While I think he'd be happy if we could do that, I didn't take his > request to be so extreme. So even if we can't handle all cases, it > makes sense to try and improve this one case. +1 As I said yesterday in a reply to Eli, modifying the fill algorithm as you suggest above would be an improvement, I think. -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 31 13:33:45 2013 Received: (at control) by debbugs.gnu.org; 31 Oct 2013 17:33:46 +0000 Received: from localhost ([127.0.0.1]:55272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbw7t-0006OT-LD for submit@debbugs.gnu.org; Thu, 31 Oct 2013 13:33:45 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:60954 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbw7r-0006OM-Ma for control@debbugs.gnu.org; Thu, 31 Oct 2013 13:33:43 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Vbw7r-0002zL-EF for control@debbugs.gnu.org; Thu, 31 Oct 2013 13:33:43 -0400 Date: Thu, 31 Oct 2013 13:33:43 -0400 Message-Id: Subject: control message for bug 15771 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.5 (-----) merge 13949 15771 From unknown Sat Jun 14 19:38:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Fri, 15 Nov 2013 07:54:01 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 02:58:34 2013 Received: (at control) by debbugs.gnu.org; 15 Nov 2013 07:58:35 +0000 Received: from localhost ([127.0.0.1]:53873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhEIU-0006jv-BL for submit@debbugs.gnu.org; Fri, 15 Nov 2013 02:58:34 -0500 Received: from mail-lb0-f175.google.com ([209.85.217.175]:35854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhEIR-0006jf-LI for control@debbugs.gnu.org; Fri, 15 Nov 2013 02:58:32 -0500 Received: by mail-lb0-f175.google.com with SMTP id p9so2424643lbv.20 for ; Thu, 14 Nov 2013 23:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=A+1WgH9QVwMeEKKIjeqSWAXNYRvFkEKUajl6VYTT4IY=; b=i6sgSADfVHB/yuZPdujFPLCTuDCbQRULAzyOKgWAVX0VIWYa5ZtcEUfAVJO3ITi54J BeiVAQNYSegj2Xdd56uCObysAOO+vtpIuO4o4Yh6w13GWLlYPu3JpDMZLvoKxmEA66S1 uOPEF6ZPApCVEK+umpSJokBWMi6smGuYNbgiAltpqndo6c0Ah3cffu/RvEtL3vC1hsps OmiPk4uTRx6b20bsLQN/GU29RnNFEQjRnWKpyn5gsRtxVxyjm1VEYrgF6xtwckoHmc6N 0SHjq3k7t8IP/3dK+67EGOma/O/ZtOTXefSACeYBE4jPsG0ertXKXIno7WRU/7wTDvFI hipw== MIME-Version: 1.0 X-Received: by 10.112.210.136 with SMTP id mu8mr3128703lbc.25.1384502305463; Thu, 14 Nov 2013 23:58:25 -0800 (PST) Received: by 10.114.176.231 with HTTP; Thu, 14 Nov 2013 23:58:25 -0800 (PST) Date: Fri, 15 Nov 2013 08:58:25 +0100 Message-ID: Subject: unmerge 13949 From: Dani Moncayo To: control@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) unmerge 13949 -- Dani Moncayo From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 29 11:27:59 2015 Received: (at control) by debbugs.gnu.org; 29 Jul 2015 15:27:59 +0000 Received: from localhost ([127.0.0.1]:33799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZKTGw-0006tY-Qt for submit@debbugs.gnu.org; Wed, 29 Jul 2015 11:27:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52165) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZKTGv-0006tQ-60 for control@debbugs.gnu.org; Wed, 29 Jul 2015 11:27:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKTGr-0003KY-6S for control@debbugs.gnu.org; Wed, 29 Jul 2015 11:27:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKTGr-0003KU-36 for control@debbugs.gnu.org; Wed, 29 Jul 2015 11:27:53 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1ZKTGq-000418-Oc for control@debbugs.gnu.org; Wed, 29 Jul 2015 11:27:52 -0400 Subject: control message for bug 21155 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Wed, 29 Jul 2015 11:27:52 -0400 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) forcemerge 13949 21155 From unknown Sat Jun 14 19:38:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Thu, 30 Jul 2015 15:36:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 06:50:15 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 10:50:16 +0000 Received: from localhost ([127.0.0.1]:57742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiJt9-0003ao-Ng for submit@debbugs.gnu.org; Tue, 22 Mar 2016 06:50:15 -0400 Received: from huan3.mail.rambler.ru ([81.19.66.33]:36198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiJt7-0003ac-OJ; Tue, 22 Mar 2016 06:50:14 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=5f2l8uUH7bGI4CT2d9S6lPNujjyiodBAlXkLPIES/64=; b=Ns3saket0pZ+LkMjuxI+mazB+7cRfw5n7t2JbGd95LAHgvjG8vSKAoUyjHOud36MKAZp69AwptQn+Qcghw0sy9S+MNwLvTMOzHV4QbiS7iVxdZwoGGZFQGCyZg1ujd7PIp2LzDk6CKl8vXMQ7MwxWn+3K5fRkjL91WJ3yhWKjq4=; Received: from [UNAVAILABLE] ([91.52.57.226]:52312 helo=[192.168.3.203]) by huan3.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiJt3-0000Dz-OY; Tue, 22 Mar 2016 13:50:11 +0300 To: control@debbugs.gnu.org, 13949@debbugs.gnu.org From: Jaakov Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Message-ID: <56F12360.5030301@ro.ru> Date: Tue, 22 Mar 2016 11:50:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/91.52.57.226 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.) From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 07:38:03 2016 Received: (at submit) by debbugs.gnu.org; 22 Mar 2016 11:38:03 +0000 Received: from localhost ([127.0.0.1]:57794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiKdP-00084n-6p for submit@debbugs.gnu.org; Tue, 22 Mar 2016 07:38:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiKdN-000841-Hh for submit@debbugs.gnu.org; Tue, 22 Mar 2016 07:38:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiKdF-0003Cf-8p for submit@debbugs.gnu.org; Tue, 22 Mar 2016 07:37:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiKdF-0003CY-5b for submit@debbugs.gnu.org; Tue, 22 Mar 2016 07:37:53 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiKd9-0000UG-DA for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 07:37:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiKd5-00039T-3W for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 07:37:47 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:54515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiKd4-000399-Q7 for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 07:37:43 -0400 Received: from [192.168.178.35] ([77.12.39.103]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0Mf1KL-1aOKwX0qV7-00OYcX for ; Tue, 22 Mar 2016 12:37:40 +0100 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: bug-gnu-emacs@gnu.org References: <56F12360.5030301@ro.ru> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <56F12EE5.20301@easy-emacs.de> Date: Tue, 22 Mar 2016 12:39:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <56F12360.5030301@ro.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zgnQco7yErl05lQLLxdyNXHUWDVYCaXrYiWeVlvs442I7FPyV3K 2tgeHW6w9LU+ycShYCeis0BE2t8dPRlqqi91gr/DoB4Ix/22n2IvKUAWEaPi5d5X0t58OoH VQi6GvOXzwvMxHQdwcgx7GTKqJuv/7M3If9Bg9swivv0CU2tiBLXqFAedzlFXV0L0wteXCF R38vqNP9bG0Or/YIimTig== X-UI-Out-Filterresults: notjunk:1;V01:K0:BhGXWyzJQ9Q=:DtkC6Blj79SG1fExvutr6g uCqzc93uWTDxcTaxFJHu7KOSizWOjga7wubIGJk6ZrHTNhAM4HIN9SQk8rLnl5OJ4RI8E/IyY zPL1LbcVWBylfeL6cG6/CEPoEeqin45PfbCr7EfHNkHah16NxXqVhNQ/NACGUjUJL9Ae8sHyZ eHV+j7EdKigGjVUUz1Tz2cQXG8fes2byw2E+ilXCrGAwld73UdkydyEZ8iG2ZsXHr3l3CdW7r a6Y5O7Q7pXxt+DfkwrpR3NvbxsjRT+ZBtV0+BGyeTriXOnNBrWaVHzDmxwbtUL6LG9deUPG8P w8BYPsmu35A86caFV6EpQbfH8CWrA8xjPhtulrXq08DdykhTIlR/yTW1YUqk2m/XnM9n7ohFO lg+9+fr78zFs0+GuchwK/hJEcn+iXkmJ86Bfrg7LrfJ7mdki4lA5XMfqCoyeSDixSz3aW4wpX w1k/9vKIfzA6jVAyNq/1XOiommhWYMmehxgQ/9aqomsf3/Y3s5sODBskfiVB3fPqtfmokHIjM MHTBOL6OttloPDHPb6yUOgHyio1J4/ndGcLYX8xonxoTRI1wGMFjWlA5ziXmSuYaG+aT1A749 PihjXx5C2rhGz1WpCbKlrwt1EdZ87WyCcFeK0s4LKWj8NskM5lx1daeb5mG7q/n/vw06BLUfU Hgo/CNOyqIJ3hfjJYO98ZXSXTbr5ebu6Hz8fEnhzyEhXn/y+HEl2yO7G0Lh8r3HmI21ORjkDb VLpHvtvLrF35qIKR X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 12:15:03 2016 Received: (at control) by debbugs.gnu.org; 22 Mar 2016 16:15:03 +0000 Received: from localhost ([127.0.0.1]:60196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiOxT-0000BT-16 for submit@debbugs.gnu.org; Tue, 22 Mar 2016 12:15:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiOxR-0000Ai-Cw for control@debbugs.gnu.org; Tue, 22 Mar 2016 12:15:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiOxG-0007TS-M1 for control@debbugs.gnu.org; Tue, 22 Mar 2016 12:14:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiOxG-0007TO-IU for control@debbugs.gnu.org; Tue, 22 Mar 2016 12:14:50 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4098 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiOxF-0008RB-U5 for control@debbugs.gnu.org; Tue, 22 Mar 2016 12:14:50 -0400 Date: Tue, 22 Mar 2016 18:14:31 +0200 Message-Id: <83zitq4hi0.fsf@gnu.org> From: Eli Zaretskii To: control@debbugs.gnu.org In-reply-to: <56F12360.5030301@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 11:50:08 +0100) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) severity 13949 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 12:16:05 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 16:16:05 +0000 Received: from localhost ([127.0.0.1]:60201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiOyT-0000EQ-9T for submit@debbugs.gnu.org; Tue, 22 Mar 2016 12:16:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiOyR-0000Cd-Gm for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 12:16:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiOyG-0007jF-Gg for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 12:15:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiOyG-0007jA-Cf; Tue, 22 Mar 2016 12:15:52 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4099 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiOyF-0000CW-Pz; Tue, 22 Mar 2016 12:15:52 -0400 Date: Tue, 22 Mar 2016 18:15:33 +0200 Message-Id: <83y49a4hga.fsf@gnu.org> From: Eli Zaretskii To: Jaakov In-reply-to: <56F12360.5030301@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 11:50:08 +0100) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. Therefore, this is still a wishlist request for a new feature, not a bug. Patches to implement such a feature are welcome. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 13:40:18 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 17:40:19 +0000 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 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=; 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 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: Eli Zaretskii References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> From: Jaakov Message-ID: <56F1837D.4060300@ro.ru> Date: Tue, 22 Mar 2016 18:40:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <83y49a4hga.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 13:52:18 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 17:52:18 +0000 Received: from localhost ([127.0.0.1]:60282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQTZ-0004F3-S5 for submit@debbugs.gnu.org; Tue, 22 Mar 2016 13:52:17 -0400 Received: from huan1.mail.rambler.ru ([81.19.66.27]:36718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQTX-0004Ev-Um for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 13:52:16 -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:Subject; bh=Y3BAGxBLHf1YYm/Bn60NCvJFT4ozUO1nL9ucJ/nzyoE=; b=lyFIoyJiZ0dky0G9r1nDLv22B3co4SZ3DTr6TYwRZzhbaXsoLn19r1+841X78rTpFKvCTUFqZi6wa/h1sECfZjXMd3SdSyYaj6Umh+laYqRABYuClwRe81uK5GODt2RJaQIlowN3HzoVGj9mjprzEzX/gbpTE8cFGdG56qgzjho=; Received: from [UNAVAILABLE] ([131.159.50.38]:31651) by huan1.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiQTW-0005ZH-SC for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 20:52:15 +0300 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> From: Jaakov Message-ID: <56F1864E.403@ro.ru> Date: Tue, 22 Mar 2016 18:52:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <83y49a4hga.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Another implementation to fill paragraph in text mode could have as well scanned through the text linewise as suggested by Stefan Monnier. I would implement just line splitting along the following idea for text-mode (not in LISP - please excuse me): [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.27 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [81.19.66.27 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Another implementation to fill paragraph in text mode could have as well scanned through the text linewise as suggested by Stefan Monnier. I would implement just line splitting along the following idea for text-mode (not in LISP - please excuse me): [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.27 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [81.19.66.27 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid Another implementation to fill paragraph in text mode could have as well scanned through the text linewise as suggested by Stefan Monnier. I would implement just line splitting along the following idea for text-mode (not in LISP - please excuse me): FOR EACH line l in the current paragraph REMARK space = whitespace or TAB c := rightmost column of l with space or -1 if none found IF c >= fill-column => 0 THEN REPEAT c' := c c := rightmost column of l|_{[0,c'[} with space or -1 if none found UNTIL c < fill-column IF c<0 THEN split line l at column c' ELSE split line l at column c ENDIF modifies := true END IF END FOR Of course, fill-paragraph needs to be much more than line splitting, so don't take my terrible piece of code too seriously, i.e., for anything except the initial idea. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 13:56:11 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 17:56:11 +0000 Received: from localhost ([127.0.0.1]:60286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQXL-0004KY-Ac for submit@debbugs.gnu.org; Tue, 22 Mar 2016 13:56:11 -0400 Received: from mout.web.de ([212.227.15.4]:63393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQXJ-0004KI-HV for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 13:56:10 -0400 Received: from drachen.dragon ([94.218.210.27]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0McnaL-1aQcZH0P7h-00Hxmt; Tue, 22 Mar 2016 18:56:02 +0100 From: Michael Heerdegen To: Jaakov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> Date: Tue, 22 Mar 2016 18:56:00 +0100 In-Reply-To: <56F1837D.4060300@ro.ru> (Jaakov's message of "Tue, 22 Mar 2016 18:40:13 +0100") Message-ID: <87egb2qtvz.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:GD7OjWOXhaaiy+vN56NWaRcOJ3Iy6w2OtfjVwuhx/wjI7N6KKJg z6t7Qh/Wyl37OD06jC4/BwthxtEAYyJhRvsS7vWJvU+KfNl3iOuhnUGfRGUsow/iGpisBmr GxY9iRFSSyDFCyGYow45GyWmxOiXLGNmhxzJioBPSzhhI/KSXoUxE1lDlLAhHo3UJLueQ7Z kkSpC5LLm7mLasRS8UtiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q/JPItvj8aY=:qj9EMOvCCOOuiM38eYe+mX +EXnYjrtJDBqpJ6a+9uy0r/tJUFv4yKv2ViZL14mrmUCWm1f6lrwwke+BQ7EaG0MRmpcV/J67 mNKVtkZ1LURO29TCRFlLJzKV1ZMXEjcJOCLwiw99PmglOlzWD5wvO2a/ignXQkq0oPhCklwfu zp9xuwEbtnCIA6s4CxMwtJH4wAr30xCTKutnL9cavdtTquiKmSstv6bLqx5t6r7AXO9UKKPTJ cebm4vi8dLaJ3HASP2gxYeF23Tlr1heDVsSLXpjJreeULoqHu+DWCa+QYRxcqQP9PwpFB3eNZ ShM5GUwGG5J/qPmqu3SzF4kXex+U3wz2mjzTiJ+GCyLYa2AkZ0Z75ZjgB8CP0FfCrky99qLO/ g3+Ag1UmUIVlMtHjYeUJdNCrVejFxJn+tkbdoQkQgwMR0qINTNwf5sxwnpJoJnijHL2HNuLbg zcokSYVMpCv/7anEQRH0pOTzSUQk5RavphmoNZIX7V6nX6erG2N2LEFT1rBisjFqtOIyrpaax VMvk8RxLc0mHFroBISu78NOu253MKIB1xLgx+e4U+sSuY7a95U4VXsgkBW62aoso6d61NKyL+ /RMEuZv8gOifEo71apWEg6omNk6PXaGXOeWbHThPOncK8QpesbWTy/I5g7rkY77AGiLnBN2b8 ab/Kb0odXe7oa48Q73Yp0cUwbfc9uuxsc60lHF7hV5ZJQPxK1+9G8oAcfiLf3IghJVAmiWSPS JyhKtIYWVs4FqgNVUifaDGyNpt77TnitruROMMDIZZoyhg2a97OU1XxCU7tTrhmEe5L0IidAM OGduQzB X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: Eli Zaretskii , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Jaakov writes: > 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. I agree. Executing one command that has the effect of (1) not changing the buffer and (2) marking the buffer modified makes no sense to the user. It makes sense from the viewpoint of the code, but not from the viewpoint of the user interface. It is confusing to the user, that's not good, so if we could change it, it would be progress, no matter how this issue is classified in technical terms. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:07:22 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 18:07:22 +0000 Received: from localhost ([127.0.0.1]:60311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQiA-0004cE-Ls for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:07:22 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:48769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQi9-0004c1-Nr for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:07:22 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2MI7FLn005536 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Mar 2016 18:07:15 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2MI7EUl017769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Mar 2016 18:07:14 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2MI7DHJ015875; Tue, 22 Mar 2016 18:07:13 GMT MIME-Version: 1.0 Message-ID: <68725c88-67d8-4e40-a8ca-6c9d5d420aad@default> Date: Tue, 22 Mar 2016 11:07:12 -0700 (PDT) From: Drew Adams To: Michael Heerdegen , Jaakov Subject: RE: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <87egb2qtvz.fsf@web.de> In-Reply-To: <87egb2qtvz.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 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. >=20 > I agree. Executing one command that has the effect of (1) not changing > the buffer and (2) marking the buffer modified makes no sense to the > user. It makes sense from the viewpoint of the code, but not from the > viewpoint of the user interface. It is confusing to the user, that's > not good, so if we could change it, it would be progress, no matter how > this issue is classified in technical terms. Yes, _IF_ we can guarantee that there are no differences between the before and after states, that is, no differences that a user or Lisp program can discern. A related question is how to handle certain changes that a user might be able to detect but that s?he might not want to have associated with the notion of buffer modification - e.g., text-property changes. Currently, all buffer modifications are handled the same way in terms of reporting/testing whether modified. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:23:20 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 18:23:20 +0000 Received: from localhost ([127.0.0.1]:60324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQxc-0004za-AU for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:23:20 -0400 Received: from mout.web.de ([212.227.17.11]:51832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiQxa-0004zN-TQ for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:23:19 -0400 Received: from drachen.dragon ([94.218.210.27]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0Ltnmz-1Zjcg241vp-011Ehi; Tue, 22 Mar 2016 19:23:08 +0100 From: Michael Heerdegen To: Drew Adams Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <87egb2qtvz.fsf@web.de> <68725c88-67d8-4e40-a8ca-6c9d5d420aad@default> Date: Tue, 22 Mar 2016 19:23:07 +0100 In-Reply-To: <68725c88-67d8-4e40-a8ca-6c9d5d420aad@default> (Drew Adams's message of "Tue, 22 Mar 2016 11:07:12 -0700 (PDT)") Message-ID: <87a8lqqsms.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:9ANNJLmVdFolYpJgrb6slfSLuw6VysGbFCqqihQyKRxt1BfID8t ndSYm41Xisi/uomasRrRD5H3N3tgVyThLcjfDpjoc+dQPSejgz+qDNc9/Z3FoOBczrH/ps1 beCDJGxINyKKBpjAqTWCFtYNbn9uKVMH4Go3gmy0mZpfLROGRwUwfdh7XvSij/cL2DNLNzO zlK0eVGDrQnZZQuifuS7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:mMLZpbcCXcg=:hEO3vYoRxsnBuoR3k7rab6 AsgM1yeBJLOJ833cpzvV40aUdhPRF8uF9OnmPa8gQxSTyKk9vj73VT0Owq7hMxVT1hNiyIbFW qy/gL1WZLWUJy3OzmgNqnqSSLrdjn6DLg9OUEE/PfbtuLvdwveyL5/sxck1j0j1bmOuRGYJVJ k+OyzOeGNlXdOdUHnKDZm5OD6EDq7olHn8fh8qQ+hcT3LjFElrAGR9wFlrEulws100F1oYKGo o9NMSbdFp1Nat5TopH4RieVx9Bqs4b+wo2MG1lCWQxZr40XgFtRotfvdYxZH9q2zwiznoyuy7 +IBC2w5BQaockh3KWuUPBsEnnK39TG4iVxqWfslAJSEqceXT1Ze+UxnoTYimqZLOTjWn+ckcO YlGzwNp0RxuuB672rvsjxOeO+y6b3eB4w+ojwInEm4i3nDvBBQ3dIVfBIbGM31GbTNU1PFica 94JfM68kYxGW625pK3eHdexcQNybnSs4aZ6oN8WzC3w8Z0GK3s2ae83y4MRfi3dtj5dhVT6nY i2c1YtdfltP23c3TMr21UDUOmmnVs9aY26K6lxYikKfq2q90F+W40nHfSQpEjQbI4CjSpCuj+ RMJIwNEwGYMKOsEJREn2f+dofhEcJPH0AcetvdtxNELdC0yNO0ijQdgY4vybiD5JGDyp+SqlA SMUVSH75DvzBDdEXm4M3yyxhvdp0me0ZfKGv7fDQu+kR5zXN78QDUYB+1WsS7xrFqIUqJsqB9 n6WHVk65HRlH09BdNqOt/olT/RDSRzdsDtInvegvWJ6+4nTj1e+VN1Jjrgc3yN1B08ZrQk/yh 8k/Ecp+ X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Drew Adams writes: > Yes, _IF_ we can guarantee that there are no differences between the > before and after states, that is, no differences that a user or Lisp > program can discern. Of course! And if we do that, I guess we should also remove the head of `buffer-undo-list' which suffers from the same problem. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:32:01 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 18:32:01 +0000 Received: from localhost ([127.0.0.1]:60344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiR61-0005Cw-Fy for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:32:01 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57003) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiR60-0005Cj-1n for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:32:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiR5r-0002bb-QC for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:31:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiR5r-0002bO-NF; Tue, 22 Mar 2016 14:31:51 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4337 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiR5n-0000Ed-K6; Tue, 22 Mar 2016 14:31:48 -0400 Date: Tue, 22 Mar 2016 20:31:28 +0200 Message-Id: <83io0e4b5r.fsf@gnu.org> From: Eli Zaretskii To: Jaakov In-reply-to: <56F1837D.4060300@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 18:40:13 +0100) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 13949@debbugs.gnu.org > From: Jaakov > Date: Tue, 22 Mar 2016 18:40:13 +0100 > > > 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. We obviously disagree. But it's pointless to continue the argument, because no matter whether this is a bug or a feature request, it must be coded to be fixed. So once again: patches are welcome, thanks in advance. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:40:36 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 18:40:36 +0000 Received: from localhost ([127.0.0.1]:60357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiREJ-0005PU-S4 for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:40:36 -0400 Received: from huan2.mail.rambler.ru ([81.19.66.15]:42120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiREI-0005PJ-N6; Tue, 22 Mar 2016 14:40:35 -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:MIME-Version:Date:Message-ID:To:From; bh=ulLUY+kpULBcPu3S2R4ZUWlPZu2GeA6NQudLJsgJjB8=; b=OD1MtkRnrpcYT9aOJzUWmEQ8+3Ubs7ifdrs8308YSvAdTR3UGSUZETA3DX70N1VT1TSClfnmViWYi4ZWGFkbYBXHuafGJIn/s3Ch9sqdpKi/gBUFv0J1weJMpQkkUzKW4JTbYJtcKQJscoVb8uajuQgT0QgfhKQ4BFFN6Zg9ft8=; Received: from [UNAVAILABLE] ([131.159.50.38]:56638) by huan2.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiREH-0007ZM-17; Tue, 22 Mar 2016 21:40:33 +0300 From: Jaakov To: control@debbugs.gnu.org, 13949@debbugs.gnu.org Message-ID: <56F191A0.9050803@ro.ru> Date: Tue, 22 Mar 2016 19:40:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 13949 normal thanks Regarding severity: I protest to the previous resetting to minor. I agree with Drew & Michael: I don't see why code-level arguments should have any validity at all. The bug is a manifestation of noncompliance of the current behavior with the documentation. A typical, normal bug, not a wishlist one. There were no new arguments from Eli, just a statement of disagreement. [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.15 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.15 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 13949 normal thanks Regarding severity: I protest to the previous resetting to minor. I agree with Drew & Michael: I don't see why code-level arguments should have any validity at all. The bug is a manifestation of noncompliance of the current behavior with the documentation. A typical, normal bug, not a wishlist one. There were no new arguments from Eli, just a statement of disagreement. [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.15 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.15 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject severity 13949 normal thanks Regarding severity: I protest to the previous resetting to minor. I agree with Drew & Michael: I don't see why code-level arguments should have any validity at all. The bug is a manifestation of noncompliance of the current behavior with the documentation. A typical, normal bug, not a wishlist one. There were no new arguments from Eli, just a statement of disagreement. I do see that a correct algorithm behind fill-paragraph would be not completely trivial even for the text mode. Thus, the bug is not 'minor' (= a problem which doesn't affect the package's usefulness, AND is presumably trivial to fix). I do not consider it 'wishlist' (= for any feature request, and also for any bugs that are very difficult to fix due to major design considerations), since it's - neither a feature - nor very difficult to fix due to major design considerations. Regarding coding: unfortunately, no patches form my side in the next few months. After that, unclear. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:42:14 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 18:42:14 +0000 Received: from localhost ([127.0.0.1]:60365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRFu-0005Sj-Dg for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:42:14 -0400 Received: from huan1.mail.rambler.ru ([81.19.66.27]:22058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRFt-0005Sb-0Y for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:42:13 -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:Subject; bh=p8njoCtJdmxT8GTDBnqM/OUSoHQPFM5BAB5Dswfrilk=; b=KKJgndp/kJN/qy8HAjhxsIK2bj9utZNuTVmNiS6lxMJbu0MD2jPeHvrThRvYbHibEayjc0gSVLcFR3q0ySxRfHNSp3bacIP4yjxl5cpb+ZiwtAVnu5shAPlSqno0yn5fJQbphFds0hFgBjni2yCzw4RmUFTkFawgz9gHHCRYcH8=; Received: from [UNAVAILABLE] ([131.159.50.38]:16981) by huan1.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiRFr-0003pg-L2 for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 21:42:11 +0300 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> From: Jaakov Message-ID: <56F19203.5040501@ro.ru> Date: Tue, 22 Mar 2016 19:42:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <83io0e4b5r.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 07:31 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 18:40:13 +0100 >> >>> 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. > > We obviously disagree. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [81.19.66.27 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.27 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 07:31 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 18:40:13 +0100 >> >>> 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. > > We obviously disagree. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.27 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [81.19.66.27 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid On 03/22/2016 07:31 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 18:40:13 +0100 >> >>> 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. > > We obviously disagree. I don't consider the previous argument for disagreement valid for the mentioned reasons. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:54:56 2016 Received: (at control) by debbugs.gnu.org; 22 Mar 2016 18:54:56 +0000 Received: from localhost ([127.0.0.1]:60385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRSC-0007Pl-DT for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:54:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRSA-0007PY-UD for control@debbugs.gnu.org; Tue, 22 Mar 2016 14:54:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiRS1-0000bf-0U for control@debbugs.gnu.org; Tue, 22 Mar 2016 14:54:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiRS0-0000bb-TW for control@debbugs.gnu.org; Tue, 22 Mar 2016 14:54:44 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4383 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiRRz-0002bd-Ul for control@debbugs.gnu.org; Tue, 22 Mar 2016 14:54:44 -0400 Date: Tue, 22 Mar 2016 20:54:25 +0200 Message-Id: <83d1qm4a3i.fsf@gnu.org> From: Eli Zaretskii To: control@debbugs.gnu.org In-reply-to: <56F191A0.9050803@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 19:40:32 +0100) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) severity 13949 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 14:56:34 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 18:56:34 +0000 Received: from localhost ([127.0.0.1]:60394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRTl-0007Sy-Uq for submit@debbugs.gnu.org; Tue, 22 Mar 2016 14:56:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37165) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRTk-0007Sj-R8 for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:56:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiRTa-0000yk-J9 for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 14:56:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiRTa-0000yg-Fg; Tue, 22 Mar 2016 14:56:22 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4384 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiRTZ-0002qf-N1; Tue, 22 Mar 2016 14:56:22 -0400 Date: Tue, 22 Mar 2016 20:56:02 +0200 Message-Id: <83bn664a0t.fsf@gnu.org> From: Eli Zaretskii To: Jaakov In-reply-to: <56F191A0.9050803@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 19:40:32 +0100) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > From: Jaakov > Date: Tue, 22 Mar 2016 19:40:32 +0100 > > severity 13949 normal > thanks > > Regarding severity: I protest to the previous resetting to minor. Your protest is respectfully noted. But please stop changing the severity. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 15:07:21 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 19:07:21 +0000 Received: from localhost ([127.0.0.1]:60412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiReD-0000ws-NI for submit@debbugs.gnu.org; Tue, 22 Mar 2016 15:07:21 -0400 Received: from huan3.mail.rambler.ru ([81.19.66.33]:4932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiReC-0000wi-P5 for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 15:07:21 -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=7XiF297htU/We0SBnP248sU+cEVMS+waxUOP21Mfjqk=; b=AC/cnJslFj4b6U+4NwRgmtz5GoR/M6UOnzR8y6erw5jItgb+4NqzjxgUciJxF5wG7ZtYqS8bNWdyPizwBn4lCncgfURJpaPEyc3OnIiRde9KLagO3Oaz4QXHd0QQG7dpDE1wmjdoTQOpjRnvpjTJpxcNfNw5+M8Fmm2ZP7gGpY4=; Received: from [UNAVAILABLE] ([131.159.50.38]:20957) by huan3.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiRe9-0006nf-NW; Tue, 22 Mar 2016 22:07:18 +0300 Subject: Re: bug#13949: (no subject) To: Eli Zaretskii References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> From: Jaakov Message-ID: <56F197E5.908@ro.ru> Date: Tue, 22 Mar 2016 20:07:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <83bn664a0t.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 07:56 PM, Eli Zaretskii wrote: >> From: Jaakov >> Date: Tue, 22 Mar 2016 19:40:32 +0100 >> >> severity 13949 normal >> thanks >> >> Regarding severity: I protest to the previous resetting to minor. > > Your protest is respectfully noted. But please stop changing the > severity. > I changed it since I consider myself right and you wrong. Obviously, you think somehow differently. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 07:56 PM, Eli Zaretskii wrote: >> From: Jaakov >> Date: Tue, 22 Mar 2016 19:40:32 +0100 >> >> severity 13949 normal >> thanks >> >> Regarding severity: I protest to the previous resetting to minor. > > Your protest is respectfully noted. But please stop changing the > severity. > I changed it since I consider myself right and you wrong. Obviously, you think somehow differently. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 03/22/2016 07:56 PM, Eli Zaretskii wrote: >> From: Jaakov >> Date: Tue, 22 Mar 2016 19:40:32 +0100 >> >> severity 13949 normal >> thanks >> >> Regarding severity: I protest to the previous resetting to minor. > > Your protest is respectfully noted. But please stop changing the > severity. > I changed it since I consider myself right and you wrong. Obviously, you think somehow differently. I think you just didn't get my point. Am I being unclear on the principal difference between (1) _what_ a routine should do and (2) _how_ it should do it? ? From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 15:11:18 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 19:11:18 +0000 Received: from localhost ([127.0.0.1]:60418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRi2-00012L-6e for submit@debbugs.gnu.org; Tue, 22 Mar 2016 15:11:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiRi1-00012A-ED for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 15:11:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiRhs-0004cI-9B for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 15:11:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiRhs-0004cE-5Z; Tue, 22 Mar 2016 15:11:08 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4411 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiRhr-0000U9-Cb; Tue, 22 Mar 2016 15:11:07 -0400 Date: Tue, 22 Mar 2016 21:10:48 +0200 Message-Id: <8360we49c7.fsf@gnu.org> From: Eli Zaretskii To: Jaakov In-reply-to: <56F197E5.908@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 20:07:17 +0100) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > Cc: 13949@debbugs.gnu.org > From: Jaakov > Date: Tue, 22 Mar 2016 20:07:17 +0100 > > On 03/22/2016 07:56 PM, Eli Zaretskii wrote: > >> From: Jaakov > >> Date: Tue, 22 Mar 2016 19:40:32 +0100 > >> > >> severity 13949 normal > >> thanks > >> > >> Regarding severity: I protest to the previous resetting to minor. > > > > Your protest is respectfully noted. But please stop changing the > > severity. > > > I changed it since I consider myself right and you wrong. Obviously, you > think somehow differently. > > I think you just didn't get my point. I'm getting your point, believe me. > Am I being unclear on the principal difference between > (1) _what_ a routine should do and > (2) _how_ it should do it? > ? I understand you, I just don't agree. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 15:53:30 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 19:53:30 +0000 Received: from localhost ([127.0.0.1]:60451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiSMs-00029K-5q for submit@debbugs.gnu.org; Tue, 22 Mar 2016 15:53:30 -0400 Received: from huan3.mail.rambler.ru ([81.19.66.33]:13455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiSMq-00029A-0c for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 15:53:28 -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=DGGlWtS1o4uBAswYglP9+D/96/z4Rz3d1fkbfUrcLKQ=; b=OX3BrUnEpnJX9zAKuo6QHDzYs4OkW9gU0rWxE+zitklPz8aavTGy4a0Bjfg5+IRmLELgVlLI60Dngv9i4aNR0WoEiTII2/GJ+onjF+1LC9Xr1l9uPyl/AipoVKI6DP+y8XqB6MLe5W82GwPodXyGhiHprWM/WVnygKVIAdEzTAo=; Received: from [UNAVAILABLE] ([131.159.50.38]:29703) by huan3.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiSMn-0004Xm-0x; Tue, 22 Mar 2016 22:53:26 +0300 Subject: Re: bug#13949: (no subject) To: Eli Zaretskii References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> From: Jaakov Message-ID: <56F1A2B4.8010401@ro.ru> Date: Tue, 22 Mar 2016 20:53:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <8360we49c7.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 08:10 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 20:07:17 +0100 >> >> On 03/22/2016 07:56 PM, Eli Zaretskii wrote: >>>> From: Jaakov >>>> Date: Tue, 22 Mar 2016 19:40:32 +0100 >>>> >>>> severity 13949 normal >>>> thanks >>>> >>>> Regarding severity: I protest to the previous resetting to minor. >>> >>> Your protest is respectfully noted. But please stop changing the >>> severity. >>> >> I changed it since I consider myself right and you wrong. Obviously, you >> think somehow differently. >> >> I think you just didn't get my point. > > I'm getting your point, believe me. > >> Am I being unclear on the principal difference between >> (1) _what_ a routine should do and >> (2) _how_ it should do it? >> ? > > I understand you, I just don't agree. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 08:10 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 20:07:17 +0100 >> >> On 03/22/2016 07:56 PM, Eli Zaretskii wrote: >>>> From: Jaakov >>>> Date: Tue, 22 Mar 2016 19:40:32 +0100 >>>> >>>> severity 13949 normal >>>> thanks >>>> >>>> Regarding severity: I protest to the previous resetting to minor. >>> >>> Your protest is respectfully noted. But please stop changing the >>> severity. >>> >> I changed it since I consider myself right and you wrong. Obviously, you >> think somehow differently. >> >> I think you just didn't get my point. > > I'm getting your point, believe me. > >> Am I being unclear on the principal difference between >> (1) _what_ a routine should do and >> (2) _how_ it should do it? >> ? > > I understand you, I just don't agree. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 03/22/2016 08:10 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 20:07:17 +0100 >> >> On 03/22/2016 07:56 PM, Eli Zaretskii wrote: >>>> From: Jaakov >>>> Date: Tue, 22 Mar 2016 19:40:32 +0100 >>>> >>>> severity 13949 normal >>>> thanks >>>> >>>> Regarding severity: I protest to the previous resetting to minor. >>> >>> Your protest is respectfully noted. But please stop changing the >>> severity. >>> >> I changed it since I consider myself right and you wrong. Obviously, you >> think somehow differently. >> >> I think you just didn't get my point. > > I'm getting your point, believe me. > >> Am I being unclear on the principal difference between >> (1) _what_ a routine should do and >> (2) _how_ it should do it? >> ? > > I understand you, I just don't agree. Your argument for not agreeing was: "the buffer text is changed (at least twice), which turns on the modified flag." If you do understand me, please observe that from the viewpoint of (1) in the described examples the buffer text is NOT changed, neither once, nor twice, not at all. (Some properties may change, but not the buffer text. Also, the user has no practical way to look at the intermediate computation.) Reason: In our case, in the view of (1) the term "buffer text is changed" is defined, somewhat diffusely, as not "the same contents as the corresponding file on the disk". Source: "The text displayed in the mode line has the following format: cs:ch-fr buf pos line (major minor) ... The next element on the mode line is the string indicated by ch. This shows two dashes (‘--’) if the buffer displayed in the window has the same contents as the corresponding file on the disk; i.e., if the buffer is “unmodified”. If the buffer is modified, it shows two stars (‘**’)." from https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html#Mode-Line Therefore, the first part of your argument is invalid. Am I being clear? From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 16:08:05 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 20:08:05 +0000 Received: from localhost ([127.0.0.1]:60463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiSay-0002Uo-VS for submit@debbugs.gnu.org; Tue, 22 Mar 2016 16:08:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiSax-0002UE-C6 for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 16:08:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiSao-0004VZ-Re for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 16:07:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiSao-0004VR-Ok; Tue, 22 Mar 2016 16:07:54 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4503 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aiSam-0007nK-CK; Tue, 22 Mar 2016 16:07:53 -0400 Date: Tue, 22 Mar 2016 22:07:33 +0200 Message-Id: <83zitq2s56.fsf@gnu.org> From: Eli Zaretskii To: Jaakov In-reply-to: <56F1A2B4.8010401@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 20:53:24 +0100) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > Cc: 13949@debbugs.gnu.org > From: Jaakov > Date: Tue, 22 Mar 2016 20:53:24 +0100 > > >> I think you just didn't get my point. > > > > I'm getting your point, believe me. > > > >> Am I being unclear on the principal difference between > >> (1) _what_ a routine should do and > >> (2) _how_ it should do it? > >> ? > > > > I understand you, I just don't agree. > > Your argument for not agreeing was: > > "the buffer text is changed (at least twice), which turns on the > modified flag." > > If you do understand me, please observe that from the viewpoint of (1) > in the described examples the buffer text is NOT changed, neither once, > nor twice, not at all. > (Some properties may change, but not the buffer text. Also, the user has > no practical way to look at the intermediate computation.) > > Reason: > > In our case, in the view of (1) the term "buffer text is changed" is > defined, somewhat diffusely, as not "the same contents as the > corresponding file on the disk". > > Source: > "The text displayed in the mode line has the following format: > cs:ch-fr buf pos line (major minor) > ... > The next element on the mode line is the string indicated by ch. This > shows two dashes (‘--’) if the buffer displayed in the window has the > same contents as the corresponding file on the disk; i.e., if the buffer > is “unmodified”. If the buffer is modified, it shows two stars (‘**’)." > from > https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html#Mode-Line > > Therefore, the first part of your argument is invalid. > > Am I being clear? Yes. But you are entirely missing the point. I'm not saying anything about the subject of this report, except this: it's an enhancement request. Why? Because (a) the code does exactly what it was designed to do, not something different; and (b) the effect of what the code does in this case is not a serious problem, like a crash or inability to do something important, it is just a minor annoyance. Therefore, the triage of the bug report as an enhancement request (a.k.a. "wishlist") is correct. Please note that I said nothing at all about whether the code should do something else, or whether the documentation should be corrected to use a different definition of what the "**" indication means. This would be a different argument, and I might even agree with you there. I'm only talking about the severity value, nothing else. OK? From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 17:58:26 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 21:58:26 +0000 Received: from localhost ([127.0.0.1]:60509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiUJl-0005I1-Lw for submit@debbugs.gnu.org; Tue, 22 Mar 2016 17:58:25 -0400 Received: from huan2.mail.rambler.ru ([81.19.66.15]:23967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiUJi-0005Hr-SE for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 17:58:23 -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=h38BtOIEtsJiv+3rWW2Q19B8v4EKZboRqyujBvpAPpk=; b=c2TFWhMJAT0FovKjiSh/Zk44tlMOFyD0IBbSidTaxK5ROtEJdUzQi97MKKdfyOaPGBy9/ngnxNrhMTvGoj6uoMG7cqDeSvkLn14tvaLmQKNnwzuVEj8EVRHZg8Typi96W8aXmtgefNSKsw72xBDY5klqZagHBHJkRHfVLQXu2sA=; Received: from [UNAVAILABLE] ([131.159.50.38]:38325) by huan2.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aiUJg-00056O-Ru; Wed, 23 Mar 2016 00:58:21 +0300 Subject: Re: bug#13949: (no subject) To: Eli Zaretskii References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> From: Jaakov Message-ID: <56F1BFFC.7090104@ro.ru> Date: Tue, 22 Mar 2016 22:58:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <83zitq2s56.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 09:07 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 20:53:24 +0100 >> >>>> I think you just didn't get my point. >>> >>> I'm getting your point, believe me. >>> >>>> Am I being unclear on the principal difference between >>>> (1) _what_ a routine should do and >>>> (2) _how_ it should do it? >>>> ? >>> >>> I understand you, I just don't agree. >> >> Your argument for not agreeing was: >> >> "the buffer text is changed (at least twice), which turns on the >> modified flag." >> >> If you do understand me, please observe that from the viewpoint of (1) >> in the described examples the buffer text is NOT changed, neither once, >> nor twice, not at all. >> (Some properties may change, but not the buffer text. Also, the user has >> no practical way to look at the intermediate computation.) >> >> Reason: >> >> In our case, in the view of (1) the term "buffer text is changed" is >> defined, somewhat diffusely, as not "the same contents as the >> corresponding file on the disk". >> >> Source: >> "The text displayed in the mode line has the following format: >> cs:ch-fr buf pos line (major minor) >> ... >> The next element on the mode line is the string indicated by ch. This >> shows two dashes (‘--’) if the buffer displayed in the window has the >> same contents as the corresponding file on the disk; i.e., if the buffer >> is “unmodified”. If the buffer is modified, it shows two stars (‘**’)." >> from >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html#Mode-Line >> >> Therefore, the first part of your argument is invalid. >> >> Am I being clear? > > Yes. > > But you are entirely missing the point. I'm not saying anything about > the subject of this report, except this: it's an enhancement request. > Why? Because (a) the code does exactly what it was designed to do, > not something different; and (b) the effect of what the code does in > this case is not a serious problem, like a crash or inability to do > something [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.15 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.15 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03/22/2016 09:07 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 20:53:24 +0100 >> >>>> I think you just didn't get my point. >>> >>> I'm getting your point, believe me. >>> >>>> Am I being unclear on the principal difference between >>>> (1) _what_ a routine should do and >>>> (2) _how_ it should do it? >>>> ? >>> >>> I understand you, I just don't agree. >> >> Your argument for not agreeing was: >> >> "the buffer text is changed (at least twice), which turns on the >> modified flag." >> >> If you do understand me, please observe that from the viewpoint of (1) >> in the described examples the buffer text is NOT changed, neither once, >> nor twice, not at all. >> (Some properties may change, but not the buffer text. Also, the user has >> no practical way to look at the intermediate computation.) >> >> Reason: >> >> In our case, in the view of (1) the term "buffer text is changed" is >> defined, somewhat diffusely, as not "the same contents as the >> corresponding file on the disk". >> >> Source: >> "The text displayed in the mode line has the following format: >> cs:ch-fr buf pos line (major minor) >> ... >> The next element on the mode line is the string indicated by ch. This >> shows two dashes (‘--’) if the buffer displayed in the window has the >> same contents as the corresponding file on the disk; i.e., if the buffer >> is “unmodified”. If the buffer is modified, it shows two stars (‘**’)." >> from >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html#Mode-Line >> >> Therefore, the first part of your argument is invalid. >> >> Am I being clear? > > Yes. > > But you are entirely missing the point. I'm not saying anything about > the subject of this report, except this: it's an enhancement request. > Why? Because (a) the code does exactly what it was designed to do, > not something different; and (b) the effect of what the code does in > this case is not a serious problem, like a crash or inability to do > something [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.15 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.15 listed in wl.mailspike.net] 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 03/22/2016 09:07 PM, Eli Zaretskii wrote: >> Cc: 13949@debbugs.gnu.org >> From: Jaakov >> Date: Tue, 22 Mar 2016 20:53:24 +0100 >> >>>> I think you just didn't get my point. >>> >>> I'm getting your point, believe me. >>> >>>> Am I being unclear on the principal difference between >>>> (1) _what_ a routine should do and >>>> (2) _how_ it should do it? >>>> ? >>> >>> I understand you, I just don't agree. >> >> Your argument for not agreeing was: >> >> "the buffer text is changed (at least twice), which turns on the >> modified flag." >> >> If you do understand me, please observe that from the viewpoint of (1) >> in the described examples the buffer text is NOT changed, neither once, >> nor twice, not at all. >> (Some properties may change, but not the buffer text. Also, the user has >> no practical way to look at the intermediate computation.) >> >> Reason: >> >> In our case, in the view of (1) the term "buffer text is changed" is >> defined, somewhat diffusely, as not "the same contents as the >> corresponding file on the disk". >> >> Source: >> "The text displayed in the mode line has the following format: >> cs:ch-fr buf pos line (major minor) >> ... >> The next element on the mode line is the string indicated by ch. This >> shows two dashes (‘--’) if the buffer displayed in the window has the >> same contents as the corresponding file on the disk; i.e., if the buffer >> is “unmodified”. If the buffer is modified, it shows two stars (‘**’)." >> from >> https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html#Mode-Line >> >> Therefore, the first part of your argument is invalid. >> >> Am I being clear? > > Yes. > > But you are entirely missing the point. I'm not saying anything about > the subject of this report, except this: it's an enhancement request. > Why? Because (a) the code does exactly what it was designed to do, > not something different; and (b) the effect of what the code does in > this case is not a serious problem, like a crash or inability to do > something important, it is just a minor annoyance. > > Therefore, the triage of the bug report as an enhancement request > (a.k.a. "wishlist") is correct. > > Please note that I said nothing at all about whether the code should > do something else, or whether the documentation should be corrected to > use a different definition of what the "**" indication means. This > would be a different argument, and I might even agree with you there. > I'm only talking about the severity value, nothing else. > > OK? > I'm puzzled that I have to write the following trivialities, but no. Objections to your first paragraph: Please note that your (a) is neither usual nor directly usable: there is no easy way to check "what it was designed to do", since the original design of ** and fill-paragraph need not be - available to today users - relevant to the current state of the evolved software. So, if you do insist on (a) as a way to differentiate on whether some behavior is a bug or a feature, I would like to see this definition on the GNU pages, accompanied by a proof that it was there yesterday (e.g. a reference to the waybackmachine). And with a description of the earlier _designed_ behavior of ** and fill-paragraph. The right thing to check is not "what it was designed to do", but whether fill-paragraph produces "an incorrect or unexpected result, or [...] behave[s] in unintended ways." (See https://en.wikipedia.org/wiki/Software_bug with today's date.) Our only _common_ source of correct, expected, intended behavior descriptions is here the documentation of the mode line and fill-paragraph. With regard to this source of descriptions, ** and fill-paragraph together have a bug, not a feature by the Wikipedia definition which I have no reason to disbelieve. Your (b) "the effect ... is not a serious problem" is absolutely _unrelated_ to the GNU wishlist definition: "for any feature request, and also for any bugs that are very difficult to fix due to major design considerations.", see https://debbugs.gnu.org/Developer.html#severities Therefore, I consider the above reasons for triaging as "wishlist" flawed both in (a) and in (b). Is that enlightening? I am retracting the claim that modifies-flag or fill-properties have bugs _alone_: this claim is too imprecise. What does have a bug is the combination of ** and M-x fill-paragraph, with respect to the online documentation mentioned before. Please note that I am not claiming that the expectations, intentions, correctness statements for ** and fill-paragraph were clearly expressed. In fact, they are very diffusely expressed. However, if you downgrade this bug report based on the fact of the imprecision of the descriptions of the results/behavior, I urge you to downgrade virtually all other bug reports about routines with a comparable or worse level of documentation. I.e., probably every single report in the emacs bug database. If you do not do that, I see no reason to keep the bug report downgraded and urge you to upgrade this bug report to 'normal'. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 22 18:38:38 2016 Received: (at 13949) by debbugs.gnu.org; 22 Mar 2016 22:38:39 +0000 Received: from localhost ([127.0.0.1]:60543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiUwg-00082H-MI for submit@debbugs.gnu.org; Tue, 22 Mar 2016 18:38:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiUwf-000824-Ea for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 18:38:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiUwZ-0004Ra-Fx for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 18:38:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiUwW-0004PE-BR; Tue, 22 Mar 2016 18:38:28 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1aiUwV-0004Mb-Qp; Tue, 22 Mar 2016 18:38:27 -0400 From: Glenn Morris To: Jaakov Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> X-Spook: Spillover Abu Ghraib IRA bomb Strain NBIC TB BRLO X-Ran: SE)8r0Zk@?N%p=7C|B%i17FYGz0;MV&817#8)]&I:\vN{nBguc_Q (Jaakov's message of "Tue, 22 Mar 2016 22:58:20 +0100") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 13949 Cc: Eli Zaretskii , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Please just accept the word of several Emacs developers that this is a wishlist item. Arguing about the severity just decreases the time available to do anything productive, and makes the report noisier and less useful to read. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 23 06:49:50 2016 Received: (at 13949) by debbugs.gnu.org; 23 Mar 2016 10:49:50 +0000 Received: from localhost ([127.0.0.1]:60874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aigMI-0001ix-C3 for submit@debbugs.gnu.org; Wed, 23 Mar 2016 06:49:50 -0400 Received: from mout.gmx.net ([212.227.15.18]:51559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiVyI-0002k9-PC for 13949@debbugs.gnu.org; Tue, 22 Mar 2016 19:44:23 -0400 Received: from [193.147.107.1] by 3capp-gmx-bs05.server.lan (via HTTP); Wed, 23 Mar 2016 00:44:16 +0100 MIME-Version: 1.0 Message-ID: From: "Petros Travioli" To: 13949@debbugs.gnu.org Subject: `fill-paragraph' should not always put the buffer as modified Content-Type: text/plain; charset=UTF-8 Date: Wed, 23 Mar 2016 00:44:16 +0100 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:w1PHQDsIAzMwEpLYNzr1mBH5moLo33nhVetvE1wceBF oeWBaq9eGweeJwnEIrhkkfoJPqauW1g1KlA7gNXixeRA3z9CpL F4WYq9kIyGErwM3pkSUBSSZTOQDA38rGU+FX6MiknzyMrlgVMw Y58vz4H5dRypQBn6TV8+yqYbJ/gTfJsdAwhEvY9nzP4TJ91Jnu veeHQZjyN5fjFOYmKd/T+Q9vUmUEycEUrEhjc/9Aga8LVA+Gkq RwhRY3Nj41UBxOTClsTeKNgxuZiscz265wnr4Q0Qmcma3zecvV HM/tqg= X-UI-Out-Filterresults: notjunk:1;V01:K0:2a6dGaK+57c=:rkTTmSaEuYEbCtenzPig+U kGKAiO4QX3W6POMjG2o9/bjkCizAjKsRU0b2wZEYVCVWlIkja8ylSkliqQz3qHfBp/qKYAed9 eVVbRQ3qGcfUCK+FJ5IHuOy3ONd8e9ReBUEnb6MKyMnXaogvwvnDWQ3q0IdHH6g8uq8uSCFaB P5506jKMaEgyrRAIyCKJGJ+W0b3itAl8SuQ81OKfeYu4TnSG0SAoDaHNd8Jjz6uVjtIeFn2Hg tQwl4DDbJZFHnKhZCbhcXMXCyoHzCkzyyzchxOMOE12fl+MKKgPtV/ixJ8T4xhlu4uRgF46Ev GTQRw7JwhaY5huxDmjxq51ozDZRGC6E3Z1yU8Gg1McgGoUqkD/I3YdghXfB2kOxfime0xT9t7 wKVT7waeZZY5V7GbvlJSy/v/SfAxAFZXtriOk66+26o6MXJe0sFC0lYjBKiQOlW6uXsh4F8Ei wgn0yjTITQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 X-Mailman-Approved-At: Wed, 23 Mar 2016 06:49:49 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Funny that the view at GNU's own page https://debbugs.gnu.org/Developer.html#severities really is oblivious with respect to the seriousness of problems when defining wishlists. Of course, users cannot be blamed for that. Btw., the modifying-issue of fill-paragraph affects me, too. Petros From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 23 11:57:44 2016 Received: (at 13949) by debbugs.gnu.org; 23 Mar 2016 15:57:44 +0000 Received: from localhost ([127.0.0.1]:34607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailAG-0002od-FD for submit@debbugs.gnu.org; Wed, 23 Mar 2016 11:57:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60341) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailAF-0002oP-A1 for 13949@debbugs.gnu.org; Wed, 23 Mar 2016 11:57:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ailA6-0001wG-Vt for 13949@debbugs.gnu.org; Wed, 23 Mar 2016 11:57:38 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailA6-0001wC-SQ; Wed, 23 Mar 2016 11:57:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1898 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ailA5-0008U0-N4; Wed, 23 Mar 2016 11:57:34 -0400 Date: Wed, 23 Mar 2016 17:57:17 +0200 Message-Id: <83mvpp2nmq.fsf@gnu.org> From: Eli Zaretskii To: Jaakov In-reply-to: <56F1BFFC.7090104@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 22:58:20 +0100) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > Cc: 13949@debbugs.gnu.org > From: Jaakov > Date: Tue, 22 Mar 2016 22:58:20 +0100 > > > But you are entirely missing the point. I'm not saying anything about > > the subject of this report, except this: it's an enhancement request. > > Why? Because (a) the code does exactly what it was designed to do, > > not something different; and (b) the effect of what the code does in > > this case is not a serious problem, like a crash or inability to do > > something important, it is just a minor annoyance. > > > > Therefore, the triage of the bug report as an enhancement request > > (a.k.a. "wishlist") is correct. > > > > Please note that I said nothing at all about whether the code should > > do something else, or whether the documentation should be corrected to > > use a different definition of what the "**" indication means. This > > would be a different argument, and I might even agree with you there. > > I'm only talking about the severity value, nothing else. > > > > OK? > > > I'm puzzled that I have to write the following trivialities, but no. > > Objections to your first paragraph: > > Please note that your (a) is neither usual nor directly usable: there is > no easy way to check "what it was designed to do", since the original > design of ** and fill-paragraph need not be > - available to today users > - relevant to the current state of the evolved software. Of course, there's a way: we, the Emacs developers, know very well how this was designed. The buffer-modified indication is set upon each modification of buffer text, and is reset by saving the buffer to a file or by a direct manual action, as in M-~. That is how it's designed to work, and that's what it does. > So, if you do insist on (a) as a way to differentiate on whether some > behavior is a bug or a feature, I would like to see this definition on > the GNU pages, accompanied by a proof that it was there yesterday (e.g. > a reference to the waybackmachine). And with a description of the > earlier _designed_ behavior of ** and fill-paragraph. You have it above. If that's not official enough for you, I'm sorry, but we don't have enough resources to satisfy your requests for such documentation (and you don't have any real right to demand it to begin with). > The right thing to check is not "what it was designed to do", but > whether fill-paragraph produces "an incorrect or unexpected result, or > [...] behave[s] in unintended ways." (See > https://en.wikipedia.org/wiki/Software_bug with today's date.) Our only > _common_ source of correct, expected, intended behavior descriptions is > here the documentation of the mode line and fill-paragraph. With regard > to this source of descriptions, ** and fill-paragraph together have a > bug, not a feature by the Wikipedia definition which I have no reason to > disbelieve. I'm not arguing whether or not there's a bug, I'm arguing only about its severity level. > Your (b) "the effect ... is not a serious problem" is absolutely > _unrelated_ to the GNU wishlist definition: "for any feature request, > and also for any bugs that are very difficult to fix due to major design > considerations.", see > https://debbugs.gnu.org/Developer.html#severities Wishlist is the only level provided by debbugs which means "enhancement", so that's what we use. If there were a better named value, we would probably use it instead. > Therefore, I consider the above reasons for triaging as "wishlist" > flawed both in (a) and in (b). I'm not surprised. > Is that enlightening? Not really. > Please note that I am not claiming that the expectations, intentions, > correctness statements for ** and fill-paragraph were clearly expressed. > In fact, they are very diffusely expressed. However, if you downgrade > this bug report based on the fact of the imprecision of the descriptions > of the results/behavior, I urge you to downgrade virtually all other bug > reports about routines with a comparable or worse level of > documentation. I.e., probably every single report in the emacs bug > database. If you do not do that, I see no reason to keep the bug report > downgraded and urge you to upgrade this bug report to 'normal'. Sorry, I'm not going to upgrade it. And I don't really understand why you keep insisting on that, since the severity has no effect whatsoever on either the probability that the bug will be fixed, nor on our willingness to accept patches for that if and when submitted. IOW, this argument is a complete waste of time and energy. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 23 11:58:23 2016 Received: (at 13949) by debbugs.gnu.org; 23 Mar 2016 15:58:23 +0000 Received: from localhost ([127.0.0.1]:34611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailAs-0002pv-Rb for submit@debbugs.gnu.org; Wed, 23 Mar 2016 11:58:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailAr-0002pk-9l for 13949@debbugs.gnu.org; Wed, 23 Mar 2016 11:58:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ailAh-00028O-Vz for 13949@debbugs.gnu.org; Wed, 23 Mar 2016 11:58:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailAh-00028G-Se; Wed, 23 Mar 2016 11:58:11 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1899 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ailAg-0000bC-JP; Wed, 23 Mar 2016 11:58:11 -0400 Date: Wed, 23 Mar 2016 17:57:54 +0200 Message-Id: <83lh592nlp.fsf@gnu.org> From: Eli Zaretskii To: Glenn Morris In-reply-to: (message from Glenn Morris on Tue, 22 Mar 2016 18:38:27 -0400) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 13949 Cc: j_k_v@ro.ru, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > From: Glenn Morris > Cc: Eli Zaretskii , 13949@debbugs.gnu.org > Date: Tue, 22 Mar 2016 18:38:27 -0400 > > Please just accept the word of several Emacs developers that this is a > wishlist item. Arguing about the severity just decreases the time > available to do anything productive, and makes the report > noisier and less useful to read. I couldn't agree more. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 23 13:45:29 2016 Received: (at 13949) by debbugs.gnu.org; 23 Mar 2016 17:45:29 +0000 Received: from localhost ([127.0.0.1]:34685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aimqX-0005Wy-9G for submit@debbugs.gnu.org; Wed, 23 Mar 2016 13:45:29 -0400 Received: from huan3.mail.rambler.ru ([81.19.66.33]:53464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aimqU-0005Wh-No; Wed, 23 Mar 2016 13:45:27 -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:Subject; bh=ad38/jO5+yrwF+eDI95p+JYhz3Ziggc+zM16U/RiQuI=; b=zVtBSJeVphcLZAwO90Ld0ZIquqEG8ymzqmbRcEc/UYCK0YDuDHinagFMyPbmZ7tF4QyYJJAfzfQ2n/sXtPpy5ADvwaEGdp8WqZ8QcWralEkVsUFtaCse+auDInA1cBg6q/Bh+Q5Nm6u4pLGPhuxCbmxOZjq0xQJqisHd94zHdgo=; Received: from [UNAVAILABLE] ([131.159.50.38]:5427) by huan3.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1aimqQ-0000nu-4o; Wed, 23 Mar 2016 20:45:24 +0300 Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> <83lh592nlp.fsf@gnu.org> From: Jaakov Message-ID: <56F2D631.7030407@ro.ru> Date: Wed, 23 Mar 2016 18:45:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <83lh592nlp.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/131.159.50.38 X-Spam-Score: 4.4 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 13949 normal thanks >> Please just accept the word of several Emacs developers that this is a >> wishlist item. Arguing about the severity just decreases the time >> available to do anything productive, and makes the report >> noisier and less useful to read. > I couldn't agree more. [...] Content analysis details: (4.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 13949 Cc: control@debbugs.gnu.org, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 4.4 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 13949 normal thanks >> Please just accept the word of several Emacs developers that this is a >> wishlist item. Arguing about the severity just decreases the time >> available to do anything productive, and makes the report >> noisier and less useful to read. > I couldn't agree more. [...] Content analysis details: (4.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.33 listed in list.dnswl.org] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [81.19.66.33 listed in wl.mailspike.net] 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders severity 13949 normal thanks >> Please just accept the word of several Emacs developers that this is a >> wishlist item. Arguing about the severity just decreases the time >> available to do anything productive, and makes the report >> noisier and less useful to read. > I couldn't agree more. In other words, you disregard your own https://debbugs.gnu.org/Developer.html#severities (importance or seriousness is not influencing "wishlist") and are asking to accept it unconditionally. Of course not! I am going to upgrade the severity level this last time but not any more, because, apparently, you downgraded it before and have more resources to do that. But, you know, I don't have to - provide patches or - donate anything to FSF if you repair that bug. I could have done that. Keep this bug around with you. Bye-bye! From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 23 13:57:44 2016 Received: (at control) by debbugs.gnu.org; 23 Mar 2016 17:57:44 +0000 Received: from localhost ([127.0.0.1]:34695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ain2O-0005om-Jo for submit@debbugs.gnu.org; Wed, 23 Mar 2016 13:57:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ain2N-0005oY-2o for control@debbugs.gnu.org; Wed, 23 Mar 2016 13:57:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ain2E-0007Y3-OS for control@debbugs.gnu.org; Wed, 23 Mar 2016 13:57:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ain2E-0007Xz-Ks for control@debbugs.gnu.org; Wed, 23 Mar 2016 13:57:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2097 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ain2E-0006mr-0p for control@debbugs.gnu.org; Wed, 23 Mar 2016 13:57:34 -0400 Date: Wed, 23 Mar 2016 19:57:18 +0200 Message-Id: <83io0d2i2p.fsf@gnu.org> From: Eli Zaretskii To: control@debbugs.gnu.org In-reply-to: <56F2D631.7030407@ro.ru> (message from Jaakov on Wed, 23 Mar 2016 18:45:21 +0100) Subject: Re: bug#13949: (no subject) References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> <83lh592nlp.fsf@gnu.org> <56F2D631.7030407@ro.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) severity 13949 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 26 19:33:56 2016 Received: (at 13949) by debbugs.gnu.org; 26 Mar 2016 23:33:56 +0000 Received: from localhost ([127.0.0.1]:38987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ajxiO-0004HY-6d for submit@debbugs.gnu.org; Sat, 26 Mar 2016 19:33:56 -0400 Received: from mail-pf0-f178.google.com ([209.85.192.178]:35009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ajxiM-0004HE-OH for 13949@debbugs.gnu.org; Sat, 26 Mar 2016 19:33:55 -0400 Received: by mail-pf0-f178.google.com with SMTP id n5so108226861pfn.2 for <13949@debbugs.gnu.org>; Sat, 26 Mar 2016 16:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version; bh=2OkpBgXFDcfxhDQ5wAUU8Hfn6+zPRUjgtBPHk7aikfg=; b=Vy7sRBxjM4/rMreE8FQMfGNOBs2Z2BiAjsyRZ5nCszE1YPnLt/IqTP8a5Kk4XjrSNJ 3qR9BJCy6yHhW79Ij8rVxaeDfQVUxmu2BZX36z6Y1lG83WZmjx/GGCUsCDYwWtymy41M NSXINJJk49hIpdJRwmk10jd0IIBVExlctw3YFf4Nx37dO1VfhhAA50tQsxzCEmO7fTgm 1VUXHgYhPWCqV2iW5UZYMe2DpeXPfw0NU6761ZtA6YygSUK34DniH42wF2FvscQlucey mIN7sZLc1SPOtR+duEF9Rnjl/86V2fMpVI0fR1GcpBlmeHarXj5C3IMm7lM4pDskzwvK QufQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:mime-version; bh=2OkpBgXFDcfxhDQ5wAUU8Hfn6+zPRUjgtBPHk7aikfg=; b=iSS1qT4Aflyhiy2i1/NZGVqNXdMGZPmd2HBCtYENwNSRJnRqIt5xkIP5WoBfrE4OdE CFZnihQ7iMORwiXZ8A1yOzjPl4+6e+kfH2Zqqx7HIznj76kZ91E259tPatCrcgpLTbrh 28XMc9G+/JqK4vMGMEZ7egg3U0PJTNuCva30mt50awiGcQ7pCyEyhlQk+f+8/dhESOHa tvZomqzaTXsz2+7R9D0Rgt1TkUgCIJ5GbjrKlVrB/CXtbnRqY1CfK7Ohe5PfzqmDUbMr VdKq7r9L8yDbFOMNwywx/88LQMLpaQ5wKYyRMrRB1r20loT2JWycgW1LWCgAV+PU/UUt Owdg== X-Gm-Message-State: AD7BkJJ7cHQDp8A+iU4kGZFcb7X2edlzRDixjnQDe4G4rIALRimDtOs5GQNSziH/75vX+w== X-Received: by 10.98.9.83 with SMTP id e80mr31624503pfd.34.1459035229263; Sat, 26 Mar 2016 16:33:49 -0700 (PDT) Received: from Hermes.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id by3sm25389937pab.39.2016.03.26.16.33.48 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 26 Mar 2016 16:33:48 -0700 (PDT) From: John Wiegley X-Google-Original-From: "John Wiegley" Received: by Hermes.local (Postfix, from userid 501) id 557B24FB4461; Sat, 26 Mar 2016 16:33:47 -0700 (PDT) To: Glenn Morris Subject: Re: bug#13949: (no subject) In-Reply-To: (Glenn Morris's message of "Tue, 22 Mar 2016 18:38:27 -0400") Date: Sat, 26 Mar 2016 16:33:42 -0700 Message-ID: References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.92 (darwin) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >>>>> Glenn Morris writes: > Please just accept the word of several Emacs developers that this is a > wishlist item. Arguing about the severity just decreases the time available > to do anything productive, and makes the report noisier and less useful to > read. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.192.178 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (jwiegley[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.192.178 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 13949 Cc: Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >>>>> Glenn Morris writes: > Please just accept the word of several Emacs developers that this is a > wishlist item. Arguing about the severity just decreases the time available > to do anything productive, and makes the report noisier and less useful to > read. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.192.178 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.192.178 listed in wl.mailspike.net] 2.0 SLIGHTLY_BAD_SUBJECT Subject contains something slightly spammy -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (jwiegley[at]gmail.com) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Glenn Morris writes: > Please just accept the word of several Emacs developers that this is a > wishlist item. Arguing about the severity just decreases the time availab= le > to do anything productive, and makes the report noisier and less useful to > read. Jaakov, if you disagree about the setting of a bug's priority, you can appe= al the decision to me, as maintainer. In this case, I agree with Eli, who in general has complete authority to set priorities as he sees fit, since he is one of the primary developers who addresses these issues. I appreciate you bringing the matter to our attention, but further discussi= on on the topic of severity is not the best way to spend our collective time. Happy hacking, =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJW9xxWAAoJEMFE2PTxn+Yw3fAMAJhkhO97l3uxeaHJy/ZELQnZ GSbvSMaCTaOKjFYFuuCQDErWGWfYKgEa79gAdGVG17Fj0DgS/XSIhrWsk4mwsjeT Yy0mLP68r7p3QBXTJ+u4Gwlunb3/hTNV/8YlD9krAqz2xTyv0LxsIZU2LxNsBUyp J5Zid+00u21smKItbrmDnW72+3mTn+h26Fy9cIVmm3SzzMdCpVIEk03lDfxE9jKI KR6x0lfmOze/wt0gpaOiVo980DnKNPH1TO3Q1zayA2kCnuNypqsaEq10ZjS4GCxU wYpQtQyqhw0fU6rXn1X+GEW2d9oGVtA4adswi8Y80jo9NDj94Z1q0fwCHDRD3kRG GioIxq5npdag8H7g8QjwzX3k9ETb446i/LDXSUCpZi/yDwHppiFeG1SvxZvt5i7V SCoF+JQHBssLFred/Cqo24p0MIRMvZ5s9ei6YdAg2fZAOVghWQGB9+/7ENKuMrsk T053K7mPlCZ53etT/AQg6/Uok8U/qdd92pGTWlw5lQ== =MoEr -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 26 19:47:01 2016 Received: (at 13949) by debbugs.gnu.org; 26 Mar 2016 23:47:01 +0000 Received: from localhost ([127.0.0.1]:38992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ajxv3-0004dl-F6 for submit@debbugs.gnu.org; Sat, 26 Mar 2016 19:47:01 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:33223) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ajxv0-0004dY-VG for 13949@debbugs.gnu.org; Sat, 26 Mar 2016 19:46:59 -0400 Received: by mail-pf0-f174.google.com with SMTP id 4so108761048pfd.0 for <13949@debbugs.gnu.org>; Sat, 26 Mar 2016 16:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version; bh=G2bBp05XbEx8dgPBMqOQ+j8qAbBqN37Wg8WqrpegxhU=; b=z16eR0bJ5JQxBSTBu3Sob61yhWVl+5iInXsZtshjm2aTv1XgnSrYGuiLB+bIkNsrQt Q/1vl/uDgkILRwyjp2K6rFVw147eMKkIr7I9hUn2SRTIIL70Dcy3GO5/zZlTEW65tkCn GtRn68FR9tZdqS/FnLRav5cvPsRZIq0gsmGOrKT00ycyGqG/L63OZKOV9RDN4bsM4yk7 wOmGxiQweO1ClmrXYlRh9m3V7BHKi8anN7Z6rVMKbebrRBxI4kJvRvL5BW+u1IhJKtYB qP1qOt26dLptfgrhVru09lNvUmBd3vS/+CapsxJhKhEfy8deQ6kt2SxY9kmZyBUus86k /rlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:mime-version; bh=G2bBp05XbEx8dgPBMqOQ+j8qAbBqN37Wg8WqrpegxhU=; b=lvc2wg+ahFzn8DkQgCy+BA6VspCLBAQ4/aUYliYFT2aT1Y1PFUA7zExfaCSyaqkJX6 MYtSAXUYd+Tigjqx3qnhNM1anJCOz3I5ykT4R/EcTmuzxbM5DmcCcw8gBhPKvgB5hKId mjuTKDpRLlbsSnzt6rUxcjhCFLdRayzvZmgZoAoLu4ih5gRNmBdHA+hrey0tKkJeZp0a rcLX3lNQ3fxmZSUVtxiln4NE3qmgivRqWPyVwoId2/PSa21ucuEFjUVgWao7O4fMn28c FJ65JvVmc91Kx4Xil8o21QgEYfvpQTF5agwtrg33t3az6EzKNd78iOCOHTcl1TLATuI5 E0lA== X-Gm-Message-State: AD7BkJInY88K8T1Q4BJVrNQAsbYj9UcW8vN5B0PvKWr1UAH/xTAr0onKsSKZR42tjG7l5g== X-Received: by 10.98.34.200 with SMTP id p69mr31430935pfj.114.1459036013197; Sat, 26 Mar 2016 16:46:53 -0700 (PDT) Received: from Hermes.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id h2sm25381958pfd.91.2016.03.26.16.46.52 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 26 Mar 2016 16:46:52 -0700 (PDT) From: John Wiegley X-Google-Original-From: "John Wiegley" Received: by Hermes.local (Postfix, from userid 501) id C85C54FB44D6; Sat, 26 Mar 2016 16:46:51 -0700 (PDT) To: Jaakov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified In-Reply-To: <56F19203.5040501@ro.ru> (Jaakov's message of "Tue, 22 Mar 2016 19:42:11 +0100") Date: Sat, 26 Mar 2016 16:46:49 -0700 Message-ID: References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> <56F19203.5040501@ro.ru> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.92 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) severity 13949 wishlist thanks >>>>> Jaakov writes: > I don't consider the previous argument for disagreement valid for the > mentioned reasons. Hi Jaakov, Eli does not have to convince you of anything: If he wants to work on a bug, he will; if he doesn't, he won't. Setting the priority does not determine what our developers decide to work on, it only serves as a general classification. So you are welcome to express your thoughts on the relevance of a bug, but there is no cause for argument; also, please stop adjusting bug priorities. As to your point, I like the distinction you're making. In fact, one could imagine a guarding form that could be used by functions like `fill-paragraph': (modified-only-if-changed FORM) This would save the current buffer-modification flag, and perform some check at the end to verify changes were actually made before allowing it to be set (such as checking the textual content of a filled region for real textual modifications). However, while great intellectually, this does have it downsides: 1. The complexity of our code is increased for a problem that is not severe. 2. There is a performance cost, especially if the fill region is huge. So we must ask ourselves: What will fixing this issue actually solve? We'd no longer modify timestamps when unnecessary, and the user wouldn't feel compelled to save at times when it is not needed. That is all I can think of. Therefore, this bug is truly a wishlist item. I've noticed over the past couple of decades that M-q always sets my modified flag. It never once occurred to me that this should be considered a problem. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 26 23:31:30 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 03:31:30 +0000 Received: from localhost ([127.0.0.1]:39092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ak1QH-0001ni-MZ for submit@debbugs.gnu.org; Sat, 26 Mar 2016 23:31:29 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:35481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ak1QF-0001nR-1E for 13949@debbugs.gnu.org; Sat, 26 Mar 2016 23:31:27 -0400 Received: from smtp.movistar.es (smtp11.acens.net [86.109.99.135]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id 86E5F4272; Sun, 27 Mar 2016 05:31:20 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.56F75408.00B5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BC428E0347453D; Sun, 27 Mar 2016 03:31:36 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: John Wiegley Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> <56F19203.5040501@ro.ru> Date: Sun, 27 Mar 2016 05:31:19 +0200 In-Reply-To: (John Wiegley's message of "Sat, 26 Mar 2016 16:46:49 -0700") Message-ID: <87a8lkd2bc.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) John Wiegley writes: > So we must ask ourselves: What will fixing this issue actually solve? We'd no > longer modify timestamps when unnecessary, and the user wouldn't feel > compelled to save at times when it is not needed. That is all I can think of. > Therefore, this bug is truly a wishlist item. > > I've noticed over the past couple of decades that M-q always sets my modified > flag. It never once occurred to me that this should be considered a problem. Emacs thinks that the buffer is modified when actually it isn't, and gives this false information to the user and to itself. So we can't no longer rely on the modeline indicator to know if the file was modified. Some features and packages (M-x compile, magit) ask the user when they are invoked and there are buffers with unsaved changes. Saving a buffer that doesn't change the file's contents (it just updates the file's timestamp) may cause undesirable effects, like triggering a lengthy build of a project. And so on. So it is not true that this "wishlist" issue has no serious effects. Emacs is well below its usual level of cleverness here. Computing hashes of the paragraph (or the whole buffer, if you wish) before and after the operation and comparing them was suggested. Luckily it is not complex at all. We already have `secure-hash' which can operate on whole buffers or ranges. I attach a quick and dirty proof of concept for fill-paragraph, which should be useful for evaluating worst-case performance impact. This approach is not enough, as there are other functions (such as lisp-fill-paragraph) that shows the same problem. The low level functions which are used by *fill-paragraph are the ones that should be patched. To Jaakov: I agree with you that this is a bug, and not a minor one at that. However, the severity associated to this or any other report is mostly irrelevant. Solving the problem depends on the existence of someone who is willing to fix the issue. Almost all contributors here work on what they decide to work on, and utterly ignore those labels. diff --git a/lisp/textmodes/fill.el b/lisp/textmodes/fill.el index 100e2a2..9e1f430 100644 --- a/lisp/textmodes/fill.el +++ b/lisp/textmodes/fill.el @@ -804,6 +804,7 @@ fill-paragraph (interactive (progn (barf-if-buffer-read-only) (list (if current-prefix-arg 'full) t))) + (setq h (if (buffer-modified-p) "" (secure-hash 'md5 (current-buffer)))) (or ;; 1. Fill the region if it is active when called interactively. (and region transient-mark-mode mark-active @@ -862,7 +863,10 @@ fill-paragraph ;; fill-region. (fill-region beg end justify) (fill-region-as-paragraph beg end justify)))))) - fill-pfx))) + fill-pfx)) + (when (and (not (string= h "")) + (string= h (secure-hash 'md5 (current-buffer)))) + (set-buffer-modified-p nil))) (declare-function comment-search-forward "newcomment" (limit &optional noerror)) (declare-function comment-string-strip "newcomment" (str beforep afterp)) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 03:43:23 2016 Received: (at submit) by debbugs.gnu.org; 27 Mar 2016 07:43:23 +0000 Received: from localhost ([127.0.0.1]:39124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ak5M2-0007rv-Tv for submit@debbugs.gnu.org; Sun, 27 Mar 2016 03:43:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ak5M1-0007rh-LF for submit@debbugs.gnu.org; Sun, 27 Mar 2016 03:43:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ak5Lv-00044r-KH for submit@debbugs.gnu.org; Sun, 27 Mar 2016 03:43:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:37412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ak5Lv-00044n-Hc for submit@debbugs.gnu.org; Sun, 27 Mar 2016 03:43:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ak5Lu-0005LS-FE for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 03:43:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ak5Lp-00043v-FV for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 03:43:14 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:64848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ak5Lp-00043p-6f for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 03:43:09 -0400 Received: from [192.168.178.35] ([77.12.53.144]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MAMbS-1acxY80OWA-00BcAB for ; Sun, 27 Mar 2016 09:43:06 +0200 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: bug-gnu-emacs@gnu.org 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> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <56F78F77.8000008@easy-emacs.de> Date: Sun, 27 Mar 2016 09:44:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <87a8lkd2bc.fsf@wanadoo.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:vbM5dAMhJQjgidX55cNnJxfu+NlOKSuA5ezM2eGKwO4Fhsw5fGe kz9ZBVR+Q8uD5xaVT2QM+QtBX45UAPspw8H2hzC/I2idZSDOFtMXU3PKYVFHc3tDryP9sf0 3OFG4xf9nm3Awyc0hnr/X64sZfjU7Wc3OjLHKFQgQNKBz5sTBF8sudNTWsHk3B87/guP0/M NvlB/cTpHV3h7ZYqpZaag== X-UI-Out-Filterresults: notjunk:1;V01:K0:Zaxt/0CozSs=:SEgsP9OGzPjT4A2jC+TeP1 rfq1W1KoixfpymMg1skBKR14ZEdXZbyWmRrpcoC1JxiYxO2t+M3DsiAuQV0K8CSsnH7WAPLhW czEBANmSE9vFpiazJPgJxlK7P6+y4noV6Zgp1M5uQwQbaMoS1BMGUcWlmkq9m8chDPgiH1ov2 Jb8qmpeuzsH+uHAcNWRG2Wn6GXJHuJ3vubyqXyvgSrgLPkRD4s4xc3YgFuw1Sve1iQXee13G+ xpdUn2xmycpmkI4zML+9G7lNe15CeYIJPAUh5i7YSrfw3bz5R+AilzdqFC6AF7JT9Hesyak1X SJS5QZc+q9xzPmaz1/gdGT+h0VYTlojfKSZ6UwXeESf9Xb8H9qqirRqoAesSLTz6rikfUlAWe ucre7fbws1JwFLd7e4TROazbU3DeUIVbFPuIV8zTuxrEZP8X8F9vN4Mj6LcQX8HEjc2wZHafG 9vJCFUwnJ2LpNM9q6w/9wlCr71Fr/azK16M5guW1jIZ+UjJhXbdBcxGp1Tzgt5uyyJWD4tR9T CnDbXRDy1jiR7+EdcrG62kAemDqUtd/16Cve8uzSJpCjEKgrlsMeyn4tOLhgXOIOHx+hi4EgT FiDZY6l33YjvgAzo79lRrebdD+ktxaFaml2P3jXc5Zm7tH2J9Bmk3OJHQ/mi96TeXXxy0dF9I tMuNNi536S3gf+zy58ZKcGOCsWeKJ0ANLc3lKE3RpmTl6TdLRv5nMDK7dOiY4HyTAB148LEZs YIMyo9LlbLvQyHKW X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 27.03.2016 05:31, Óscar Fuentes wrote: > John Wiegley writes: > >> So we must ask ourselves: What will fixing this issue actually solve? We'd no >> longer modify timestamps when unnecessary, and the user wouldn't feel >> compelled to save at times when it is not needed. That is all I can think of. >> Therefore, this bug is truly a wishlist item. >> >> I've noticed over the past couple of decades that M-q always sets my modified >> flag. It never once occurred to me that this should be considered a problem. > Emacs thinks that the buffer is modified when actually it isn't, and > gives this false information to the user and to itself. So we can't no > longer rely on the modeline indicator to know if the file was modified. > > Some features and packages (M-x compile, magit) ask the user when they > are invoked and there are buffers with unsaved changes. Saving a buffer > that doesn't change the file's contents (it just updates the file's > timestamp) may cause undesirable effects, like triggering a lengthy > build of a project. And so on. So it is not true that this "wishlist" > issue has no serious effects. Emacs is well below its usual level of > cleverness here. > > Computing hashes of the paragraph (or the whole buffer, if you wish) > before and after the operation and comparing them was suggested. Luckily > it is not complex at all. We already have `secure-hash' which can > operate on whole buffers or ranges. I attach a quick and dirty proof of > concept for fill-paragraph, which should be useful for evaluating > worst-case performance impact. This approach is not enough, as there are > other functions (such as lisp-fill-paragraph) that shows the same > problem. The low level functions which are used by *fill-paragraph are > the ones that should be patched. > > To Jaakov: I agree with you that this is a bug, and not a minor one at > that. However, the severity associated to this or any other report is > mostly irrelevant. Solving the problem depends on the existence of > someone who is willing to fix the issue. Almost all contributors here > work on what they decide to work on, and utterly ignore those labels. > > > diff --git a/lisp/textmodes/fill.el b/lisp/textmodes/fill.el > index 100e2a2..9e1f430 100644 > --- a/lisp/textmodes/fill.el > +++ b/lisp/textmodes/fill.el > @@ -804,6 +804,7 @@ fill-paragraph > (interactive (progn > (barf-if-buffer-read-only) > (list (if current-prefix-arg 'full) t))) > + (setq h (if (buffer-modified-p) "" (secure-hash 'md5 (current-buffer)))) > (or > ;; 1. Fill the region if it is active when called interactively. > (and region transient-mark-mode mark-active > @@ -862,7 +863,10 @@ fill-paragraph > ;; fill-region. > (fill-region beg end justify) > (fill-region-as-paragraph beg end justify)))))) > - fill-pfx))) > + fill-pfx)) > + (when (and (not (string= h "")) > + (string= h (secure-hash 'md5 (current-buffer)))) > + (set-buffer-modified-p nil))) > > (declare-function comment-search-forward "newcomment" (limit &optional noerror)) > (declare-function comment-string-strip "newcomment" (str beforep afterp)) > > > Another solution would hash only the paragraph in question, re-format it in a temp buffer and replace original content only if changed. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 04:42:59 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 08:42:59 +0000 Received: from localhost ([127.0.0.1]:39135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ak6Hi-0000m2-UP for submit@debbugs.gnu.org; Sun, 27 Mar 2016 04:42:59 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:38185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ak6Hg-0000lu-Ja for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 04:42:57 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3qXrCM4wnCz3hjkG; Sun, 27 Mar 2016 10:42:55 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3qXrCM2jlczvhPC; Sun, 27 Mar 2016 10:42:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id vtHAYYFv6wJT; Sun, 27 Mar 2016 10:42:54 +0200 (CEST) X-Auth-Info: xlsKo0/tfM8VRsvIHVBptKmYd4xLmt6+digPDn0HsjwjlRJbkoG+2QfyaGK+Ad14 Received: from linux.local (ppp-88-217-9-29.dynamic.mnet-online.de [88.217.9.29]) by mail.mnet-online.de (Postfix) with ESMTPA; Sun, 27 Mar 2016 10:42:54 +0200 (CEST) Received: by linux.local (Postfix, from userid 501) id 1456E1E5465; Sun, 27 Mar 2016 10:42:45 +0200 (CEST) From: Andreas Schwab To: =?utf-8?Q?=C3=93scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> X-Yow: I want to kill everyone here with a cute colorful Hydrogen Bomb!! Date: Sun, 27 Mar 2016 10:42:23 +0200 In-Reply-To: <87a8lkd2bc.fsf@wanadoo.es> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Sun, 27 Mar 2016 05:31:19 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Óscar Fuentes writes: > Emacs thinks that the buffer is modified when actually it isn't, Emacs correctly tells you that the buffer has been modified. That the buffer's contents now match the file's contents is irrelevant. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 10:57:01 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 14:57:01 +0000 Received: from localhost ([127.0.0.1]:40123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akC7g-00039z-VJ for submit@debbugs.gnu.org; Sun, 27 Mar 2016 10:57:01 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akC7e-00039k-4J for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 10:56:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akC7V-0001TJ-H2 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 10:56:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akC7V-0001TF-E7; Sun, 27 Mar 2016 10:56:49 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3304 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akC7U-0002C4-Kv; Sun, 27 Mar 2016 10:56:49 -0400 Date: Sun, 27 Mar 2016 17:56:26 +0300 Message-Id: <83lh54ynol.fsf@gnu.org> From: Eli Zaretskii To: =?iso-8859-1?Q?=D3scar?= Fuentes In-reply-to: <87a8lkd2bc.fsf@wanadoo.es> (message from =?iso-8859-1?Q?=D3s?= =?iso-8859-1?Q?car?= Fuentes on Sun, 27 Mar 2016 05:31:19 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: jwiegley@gmail.com, j_k_v@ro.ru, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Óscar Fuentes > Date: Sun, 27 Mar 2016 05:31:19 +0200 > Cc: Jaakov , 13949@debbugs.gnu.org > > diff --git a/lisp/textmodes/fill.el b/lisp/textmodes/fill.el > index 100e2a2..9e1f430 100644 > --- a/lisp/textmodes/fill.el > +++ b/lisp/textmodes/fill.el > @@ -804,6 +804,7 @@ fill-paragraph > (interactive (progn > (barf-if-buffer-read-only) > (list (if current-prefix-arg 'full) t))) > + (setq h (if (buffer-modified-p) "" (secure-hash 'md5 (current-buffer)))) > (or > ;; 1. Fill the region if it is active when called interactively. > (and region transient-mark-mode mark-active > @@ -862,7 +863,10 @@ fill-paragraph > ;; fill-region. > (fill-region beg end justify) > (fill-region-as-paragraph beg end justify)))))) > - fill-pfx))) > + fill-pfx)) > + (when (and (not (string= h "")) > + (string= h (secure-hash 'md5 (current-buffer)))) > + (set-buffer-modified-p nil))) Thanks, but I'm not sure computing the hash is enough: the functions involved in refilling can change text properties, so the test should also account for that. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 10:59:12 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 14:59:12 +0000 Received: from localhost ([127.0.0.1]:40131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akC9o-0003Dj-Kl for submit@debbugs.gnu.org; Sun, 27 Mar 2016 10:59:12 -0400 Received: from smtp09.acens.net ([86.109.99.133]:15853 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akC9m-0003DV-Fw for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 10:59:11 -0400 X-CTCH-RefID: str=0001.0A0B0203.56F7F538.00A8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56E354CE0103C8D3; Sun, 27 Mar 2016 14:59:04 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Andreas Schwab Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 16:59:03 +0200 In-Reply-To: (Andreas Schwab's message of "Sun, 27 Mar 2016 10:42:23 +0200") Message-ID: <8760w8c6h4.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Andreas Schwab writes: >> Emacs thinks that the buffer is modified when actually it isn't, > > Emacs correctly tells you that the buffer has been modified. That the > buffer's contents now match the file's contents is irrelevant. It is very relevant for me and, judging by the comments of others on this and bug report and its duplicates, it is relevant for them too. The tools must be adapted to the mental model of their users. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:09:21 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:09:21 +0000 Received: from localhost ([127.0.0.1]:40187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCJd-0003Uy-KA for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:09:21 -0400 Received: from smtp10.acens.net ([86.109.99.134]:53737 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCJb-0003Uk-EA for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:09:19 -0400 X-CTCH-RefID: str=0001.0A0B0203.56F7F799.015A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56F5ABE50013B026; Sun, 27 Mar 2016 15:09:13 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Andreas =?utf-8?Q?R=C3=B6hler?= Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <56F78F77.8000008@easy-emacs.de> Date: Sun, 27 Mar 2016 17:09:12 +0200 In-Reply-To: <56F78F77.8000008@easy-emacs.de> ("Andreas \=\?utf-8\?Q\?R\=C3\=B6h\?\= \=\?utf-8\?Q\?ler\=22's\?\= message of "Sun, 27 Mar 2016 09:44:55 +0200") Message-ID: <87y494arfr.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Andreas R=C3=B6hler writes: > Another solution would hash only the paragraph in question, re-format > it in a temp buffer and replace original content only if changed. If we know the paragraph's begin and end points, we can hash just that range and then there is no need of a temporary buffer. I think that this condition is met on all cases. Anyway, I've made some experiments and hashing a 160 MB file on a 8 year old 2.4 GHz 64 bit workstation takes 2.4 seconds. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:13:16 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:13:16 +0000 Received: from localhost ([127.0.0.1]:40192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCNQ-0003aW-6O for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:13:16 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCNP-0003aK-AN for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:13:15 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2RFD94T013683 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 15:13:09 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2RFD9rs012667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 15:13:09 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2RFD6Qg026699; Sun, 27 Mar 2016 15:13:07 GMT MIME-Version: 1.0 Message-ID: <72682d8e-9fbc-40fe-b196-edbfb77076f3@default> Date: Sun, 27 Mar 2016 08:13:05 -0700 (PDT) From: Drew Adams To: Andreas Schwab , =?utf-8?B?w5NzY2FyIEZ1ZW50ZXM=?= Subject: RE: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > Emacs thinks that the buffer is modified when actually it isn't, >=20 > Emacs correctly tells you that the buffer has been modified. That the > buffer's contents now match the file's contents is irrelevant. "Irrelevant" is in the eye of the beholder. What might be relevant to given code or to a given user in a given context can be irrelevant to another. I agree that the current, fine-grained indication of whether any kind of changes have been made to the buffer is important not to lose. But it could also be useful to layer on top of this indications of other levels - particular kinds - of buffer changes. IOW, one-size-fits-all is not ideal, but we definitely do not want to lose the finest-grain indication, which is what we have now. Emacs should provide more help - more kinds of change indication - both for code and interactively, for users. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:15:57 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:15:57 +0000 Received: from localhost ([127.0.0.1]:40196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCQ1-0003ec-Il for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:15:57 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:36124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCQ0-0003eL-F8 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:15:56 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2RFFnNH030951 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 15:15:50 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2RFFn9Y015011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 15:15:49 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2RFFmVW007287; Sun, 27 Mar 2016 15:15:48 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 27 Mar 2016 08:15:47 -0700 (PDT) From: Drew Adams To: =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= , Andreas Schwab Subject: RE: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <8760w8c6h4.fsf@wanadoo.es> In-Reply-To: <8760w8c6h4.fsf@wanadoo.es> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> Emacs thinks that the buffer is modified when actually it isn't, > > > > Emacs correctly tells you that the buffer has been modified. That the > > buffer's contents now match the file's contents is irrelevant. >=20 > It is very relevant for me and, judging by the comments of others on > this and bug report and its duplicates, it is relevant for them too. >=20 > The tools must be adapted to the mental model of their users. Yes, and: 1. Different users have different use cases and different mental models. 2. The same user has different mental models, depending on the current context. 3. Code too, not just users, needs to be able to detect buffer changes. 4. There are different kinds of buffer changes. It would be good to have ways to detect these as such. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:21:56 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:21:56 +0000 Received: from localhost ([127.0.0.1]:40209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCVo-0003oU-Lg for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:21:56 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:55236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCVn-0003oG-2y for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:21:55 -0400 Received: from smtp.movistar.es (smtp08.acens.net [86.109.99.132]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id D8E4743EC; Sun, 27 Mar 2016 17:21:48 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0202.56F7FA8C.0180, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BAF1550349C376; Sun, 27 Mar 2016 15:21:48 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Drew Adams Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <8760w8c6h4.fsf@wanadoo.es> Date: Sun, 27 Mar 2016 17:21:47 +0200 In-Reply-To: (Drew Adams's message of "Sun, 27 Mar 2016 08:15:47 -0700 (PDT)") Message-ID: <87r3ewaqus.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org, Andreas Schwab X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Drew Adams writes: >> The tools must be adapted to the mental model of their users. > > Yes, and: > > 1. Different users have different use cases and different mental > models. > > 2. The same user has different mental models, depending on the > current context. > > 3. Code too, not just users, needs to be able to detect buffer > changes. > > 4. There are different kinds of buffer changes. It would be > good to have ways to detect these as such. Please provide an example were the user would benefit from marking the buffer as modified after applying a fill-paragraph operation that doesn't make a difference on the buffer contents. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:28:32 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:28:32 +0000 Received: from localhost ([127.0.0.1]:40214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCcC-0003xo-DA for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:28:32 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:36979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCcA-0003xb-Hi for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:28:31 -0400 Received: by mail-wm0-f49.google.com with SMTP id p65so72936680wmp.0 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 08:28:30 -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=gwU9X3V6P1rnhxRIXqOyhK0iliWRBleYKNOYZPDclmM=; b=U4uEBRS26FR4G8oo8XHH7OCDOPsgQzJzrVCAQhjzefAUMtywBlMDqjCb4yxEozSuf8 4oqrlDG6gCTYS20GUc4DGhsvKVkcn6FoYEvJRU9gKRhEr9EdG4k1A9AZd09NsETBwbgT 248WUnZEtD6y5DqG0zr1pyBTFNTZfqkKEJN/wLUc2HUxYsmd2EW5xy3OiXSQztTVXet0 frVmC/0oLRSXhJmXq17rwt0vp5NsAKQw4z1sOB2E6Dyzzn8i3KYnkEoB6LpkPYFFDjMP uMpsNw95gZ6lVW5/WukpZf7rXlyuf0LJzhnYDiOfGaysZEut7M4B8TLl/D02z/cSibOm XHXg== 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=gwU9X3V6P1rnhxRIXqOyhK0iliWRBleYKNOYZPDclmM=; b=E60jk0W2D7gAZCSDMPSjIlpyBzouhLDwOAYeIwLFAGQyDIqh0RaI68HxMeSYMado3H aWRJVdKqm1zoAb+RbnWP4XeVoft2No9e2hT7OuRJCZ/+QA5NyaysDSacaRX3Yu6QdwO4 NSHki+2yYq2YkcBMOEj41clzUG1sNefXxOC5Vpw3uj8X1CZ/WALgrgjs15CHDDjBIUaD mkCcLJEyF8Gx9hA08BZFodILA9RpJH86Qg6OnZ5csZpdXpb3acvrPzvKg0tsvAQpwS6Q 6MVpYOYX8ELYwQQ6Z6fqaxfkWZVqa5gY1uIqrnfSxo3eEUrSFParCwW4+5rLGLokXsTc TuDg== X-Gm-Message-State: AD7BkJJn40mvHBXazkOmXFdWkmYoeLGl7Ssi/MTLCGXF+goFrtPuBfSIrszZ1BOjqxhaMQ== X-Received: by 10.194.89.38 with SMTP id bl6mr8075841wjb.44.1459092504802; Sun, 27 Mar 2016 08:28:24 -0700 (PDT) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id et11sm20856253wjc.30.2016.03.27.08.28.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 08:28:24 -0700 (PDT) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: =?UTF-8?Q?=c3=93scar_Fuentes?= , John Wiegley 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> From: Dmitry Gutov Message-ID: <9d1fed3c-fdcb-dfe3-e04d-47680d3e0531@yandex.ru> Date: Sun, 27 Mar 2016 18:28:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <87a8lkd2bc.fsf@wanadoo.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 Cc: Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03/27/2016 06:31 AM, Óscar Fuentes wrote: > + (when (and (not (string= h "")) > + (string= h (secure-hash 'md5 (current-buffer)))) > + (set-buffer-modified-p nil))) Hashes have collisions (and md5 is a bit famous for them). So in principle, I don't think using a hash is a good choice in this case. Either way, you'd have to keep the original string around, to compare against if the hashes match. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:29:04 2016 Received: (at submit) by debbugs.gnu.org; 27 Mar 2016 15:29:04 +0000 Received: from localhost ([127.0.0.1]:40218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCci-0003yv-Lc for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:29:04 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCcg-0003yJ-Ci for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:29:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akCca-0008ME-KZ for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:28:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akCca-0008M9-Hj for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:28:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akCcZ-0007JY-Gp for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 11:28:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akCcV-0008Ld-Ee for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 11:28:55 -0400 Received: from plane.gmane.org ([80.91.229.3]:52768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akCcV-0008LX-7l for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 11:28:51 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1akCcT-000725-7X for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 17:28:49 +0200 Received: from 151.red-79-153-146.dynamicip.rima-tde.net ([79.153.146.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2016 17:28:49 +0200 Received: from ofv by 151.red-79-153-146.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2016 17:28:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: =?utf-8?Q?=C3=93scar_Fuentes?= Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Sun, 27 Mar 2016 17:28:42 +0200 Lines: 18 Message-ID: <87mvpkaqj9.fsf@wanadoo.es> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 151.red-79-153-146.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) Cancel-Lock: sha1:UqJ2jD+LXuw6PZB5VZx8irnvmj8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) Eli Zaretskii writes: > Thanks, but I'm not sure computing the hash is enough: the functions > involved in refilling can change text properties, so the test should > also account for that. The docs say: This shows two dashes (‘--’) if the buffer displayed in the window has the same contents as the corresponding file on the disk; i.e., if the buffer is unmodified. AFAIK, a file-visiting buffer is not marked as modified when text properties are applied to it. This makes sense, because text properties are not part of the contents of the corresponding file. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:29:45 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:29:45 +0000 Received: from localhost ([127.0.0.1]:40221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCdM-0003zn-UZ for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:29:45 -0400 Received: from relaycp02.dominioabsoluto.net ([217.116.26.74]:34654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCdL-0003zY-Oy for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:29:44 -0400 Received: from smtp.movistar.es (smtp08.acens.net [86.109.99.132]) by relaycp02.dominioabsoluto.net (Postfix) with ESMTP id D8712D2329; Sun, 27 Mar 2016 17:29:37 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0204.56F7FC61.0185, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BAF1550349D5A4; Sun, 27 Mar 2016 15:29:37 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 17:29:36 +0200 In-Reply-To: <83lh54ynol.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Mar 2016 17:56:26 +0300") Message-ID: <87io08aqhr.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: jwiegley@gmail.com, j_k_v@ro.ru, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > Thanks, but I'm not sure computing the hash is enough: the functions > involved in refilling can change text properties, so the test should > also account for that. The docs say: This shows two dashes (=E2=80=98--=E2=80=99) if the buffer displayed in t= he window has the same contents as the corresponding file on the disk; i.e., if the buffer is unmodified. AFAIK, a file-visiting buffer is not marked as modified when text properties are applied to it. This makes sense, because text properties are not part of the contents of the corresponding file. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:35:32 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:35:32 +0000 Received: from localhost ([127.0.0.1]:40232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCix-00049d-Qj for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:35:31 -0400 Received: from smtp22.acens.net ([86.109.99.146]:44404 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCiw-00049J-5X for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:35:30 -0400 X-CTCH-RefID: str=0001.0A0B0202.56F7FDBC.0041, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56CC7975024EB5D3; Sun, 27 Mar 2016 15:35:24 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 17:35:23 +0200 In-Reply-To: <9d1fed3c-fdcb-dfe3-e04d-47680d3e0531@yandex.ru> (Dmitry Gutov's message of "Sun, 27 Mar 2016 18:28:22 +0300") Message-ID: <87egawaq84.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dmitry Gutov writes: > Hashes have collisions (and md5 is a bit famous for them). So in > principle, I don't think using a hash is a good choice in this case. > > Either way, you'd have to keep the original string around, to compare > against if the hashes match. Dmitry, it would be absolutely glorious if we ever find a md5 collision among a piece of text and the result of applying fill-paragraph to it. I would demand to be credited by the feat :-) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:35:32 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:35:32 +0000 Received: from localhost ([127.0.0.1]:40234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCiy-00049f-2X for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:35:32 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:60859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCiw-00049P-55 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:35:30 -0400 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 1akCis-0002nW-4w; Sun, 27 Mar 2016 17:35:28 +0200 From: Lars Magne Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEX9/fjg4NG7xqmitKQ3 Aww0FyCKmJgxBw+DT0VoMDHP1spUAA/////+//7v7diZblILeSygAAABlUlEQVQ4jd3Sv0vDQBQH 8KggDmnpLdIpduwiHYogQXSJdFcuFgeXwtG6xzN/QdNVVKgBaRFEMusgWWJHaTt0EIegnZzSFroY F+v9ahsVce8bQu59eLkL95Waf5Q0K+BJpOI+X3nr0DgPODRGtFY5rGFSR3IEhmzkCbM6iAAbab1z MP0I0JFnLKoWATLilUX/GHQjMPSXSM+A5HEBgDyFUapM+xDumQ4AiQmEVoX3IdwnoPgCQsvKYcz6 UKUgcyD9Uyxg16EQCAjDM4ihnrfyJdWpK0qXQiqZ6Wx1SnPm5aKOUMEB/VhcCiQv85keDTLLxStz 51ovFtQ6ULr9fiA1B2SDiq1hfig9q9I9AIEXctKqq+U4oCm0klbVdW81CmQPCnXy6+QGXyu267qa hg3SR9ksOy692gYZYGIghMSnehTaHFxtewKKzMJwI+RuAjGeEi9tT6BAoTeOT/uDyb2A3jRXD0wE JKKBe6RH5lD7nsR5IhRQzf8R0YWqTWHT/5XdQfXkDR2O+wLYcmXDA/Sl9U/aZx2+ACk4Di7693OD AAAAAElFTkSuQmCC Date: Sun, 27 Mar 2016 17:35:25 +0200 In-Reply-To: <9d1fed3c-fdcb-dfe3-e04d-47680d3e0531@yandex.ru> (Dmitry Gutov's message of "Sun, 27 Mar 2016 18:28:22 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Dmitry Gutov writes: > On 03/27/2016 06:31 AM, =D3scar Fuentes wrote: > >> + (when (and (not (string=3D h "")) >> + (string=3D h (secure-hash 'md5 (current-buffer)))) >> + (set-buffer-modified-p nil))) > > Hashes have collisions (and md5 is a bit famous for them). So in > principle, I don't think using a hash is a good choice in this case. md5 is famous for enabling attackers to construct strings with the same hash, not for arbitrarily making strings hash to the same result. It's less likely that the before/after `M-q' strings hash to the same md5 than cosmic rays reprogramming your Emacs into vi, so: > Either way, you'd have to keep the original string around, to compare > against if the hashes match. Not really. (Ok, I'm exaggerating. Slightly!) --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:42:47 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:42:47 +0000 Received: from localhost ([127.0.0.1]:40240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCpy-0004Jj-Ri for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:42:46 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:33963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCpx-0004JV-0G for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:42:45 -0400 Received: by mail-wm0-f43.google.com with SMTP id p65so74815596wmp.1 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 08:42:44 -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=Xd7VBgkQ+NHLinr2VGRZI1g4BCRWE//2P07/qY11uJE=; b=ilsZY9lHwa2bdnOd41dOb+kJ9v2af1vH4BfcspH5XNwQM1HqYYKdVOFMrbjTEQTVLI aCswrtMRpwcxb0NwLjsJfOVs/BNPkdj8l1sDcTiHW1Y5Nf9UXY0wudKk9UVv15GLJ6C7 WD9M9B/iSNWQFuf5lhuFJP4yHWQnkogS9Vwu7hy3Caqhm+jZLgPxksTPDV4n20w+/Znn 3bjvdGAe/yEbt4Q5rRxuCF7huU1Yd4PRrCMmiG1+Tjf7Z/xPyoU0PvTlos+mGnk1QzCc wJ5x8NC19d2fbWZeRRvKfVrtlhhT62/uQr8urOSlnMjTYPdI6ilHlaRTasrhD0VrY/6H amsg== 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=Xd7VBgkQ+NHLinr2VGRZI1g4BCRWE//2P07/qY11uJE=; b=fUtECMXDZq3k/kah3YaqWGRG6iPaZGv801e/JDG98MjiT4CvZHhUPbNh6lH6niHESf IVrxhTjuO+TeVsGHcxBse/TvKNkILVH4c9P1MFgpMxX7HiCfSTOHakcrahVNQHjHAQOQ RaoSu4OXaEQVlcg3Nq30xxawHIEA/fK44spOJYn2dJnkG35+4w3Kzfnnw6iwYIrlQ40h cfdXM0b5JrWfV9bvhEsJ2+55f49sN1qykeZiiVTDh4+RbyAElHQA9yP1V2J43hio+qmG PHBLO9kbQ4m+QtSBACvPIGV5qW35jqvIFhXdmjpZIyMHzjk0HeYYtgcOT5qj0RdUehuy Tiug== X-Gm-Message-State: AD7BkJK7GSXDcOxGuJhq8YPSzfAL7fITcbfBFlg5HZFXFaFkv3W+bfKCN/qQ8XUyCQgixw== X-Received: by 10.28.0.83 with SMTP id 80mr6772901wma.76.1459093359419; Sun, 27 Mar 2016 08:42:39 -0700 (PDT) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id gk4sm20755623wjd.7.2016.03.27.08.42.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 08:42:38 -0700 (PDT) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: Lars Magne Ingebrigtsen 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> From: Dmitry Gutov Message-ID: <83927858-0341-096f-b7e2-1322489efda8@yandex.ru> Date: Sun, 27 Mar 2016 18:42:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 Cc: =?UTF-8?Q?=c3=93scar_Fuentes?= , John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03/27/2016 06:35 PM, Lars Magne Ingebrigtsen wrote: > It's less likely that the before/after `M-q' strings hash to the same > md5 than cosmic rays reprogramming your Emacs into vi, so: And yet, why would we allow such possibility? String comparison is plenty fast already. Comparing the contents of xdisp.c to itself takes 0.2ms here. Try: (setq s (buffer-string)) (setq ss (copy-sequence s)) (benchmark 1 '(equal s ss)) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:42:53 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:42:53 +0000 Received: from localhost ([127.0.0.1]:40243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCq5-0004K1-12 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:42:53 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCq3-0004Ji-96 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:42:51 -0400 Received: by mail-wm0-f52.google.com with SMTP id p65so73166410wmp.0 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 08:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1md/JfhbWQZvRRFNgdjMroLtIppCSkFfnHT37RZb4oM=; b=Stm73glLDKQ4iFXW5ek2NqE/EWqwV05gRBCfpmBuGcIv1sn62/jNbn7EV4vyv8R8jT GKTB/IxmavDsMr0X5JqWQnHqXNjLpaYQN2ruVkv2UE2F+/6AB3ILVHLXR32P6wPF04BE MwRohwMk7sYNHzG2jUlg/925k3hlgNtLxBcbLb3oP5Qw89CnKC4HU0PBWW9pSMIKVhcd RSDZSwq+SooFFojiyk8uiR8LKt1eoqi3/FnmW9/FLR5owi03EzrcuS3sp+vEHYfC299+ OHnKotV5tXHOrXbCQZchTVXWcIPxN1AZsbu2HZltq7rbS+1drPgN8e0Nl8DgG9p5KdAR 90nQ== 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:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1md/JfhbWQZvRRFNgdjMroLtIppCSkFfnHT37RZb4oM=; b=lz8+s+skKW4pbjR7ftckqPM6ClzLKovIboAqY6V66+mGc9wW3EN25iNPFF0JAmEBnc JW99x+GVLXdIjDPWgO4xqSqhgLpr4IfGrIsg2Ts1mJeGYODZFM2DudaxD8cB3JBg5xhI ovQ9yHXYjKw8Ilh7VIW6dq2aLJYDxmUAS5I6wNd7SHzSlruKFDMwgMoBPSjDgFJ4ygPE BAl55EGrQW2rVvV4VammSUcCTz3HU5Zn4mL8iavWA4pC3xjTfALqgVRjgH0XTRNTHnEV NvZBOVBMVC8dHzmyOVz9lLyKZHmhbAE4NRZM3TJjPv6pX49GcbQq47mAmkGxz4tTetVh 8RDQ== X-Gm-Message-State: AD7BkJKeRTBZ8GEFOUD4hn7LDZeDRqxztgI6kStR5JAB6cE9Pdpk3Eh6fsS2qeUjTZQ5Sw== X-Received: by 10.194.78.83 with SMTP id z19mr23989978wjw.5.1459093365786; Sun, 27 Mar 2016 08:42:45 -0700 (PDT) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id c71sm6286479wmd.4.2016.03.27.08.42.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 08:42:45 -0700 (PDT) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: =?UTF-8?Q?=c3=93scar_Fuentes?= , 13949@debbugs.gnu.org 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> From: Dmitry Gutov Message-ID: <37404e91-f1bf-072c-ff05-a3070391003e@yandex.ru> Date: Sun, 27 Mar 2016 18:42:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <87mvpkaqj9.fsf@wanadoo.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03/27/2016 06:28 PM, Óscar Fuentes wrote: > The docs say: > > > This shows two dashes (‘--’) if the buffer displayed in the window has > the same contents as the corresponding file on the disk; i.e., if the > buffer is unmodified. That might be a documentation bug. Switch to an unmodified buffer. Type `a', and then backspace. What do you see in the status? > AFAIK, a file-visiting buffer is not marked as modified when text > properties are applied to it. It is. If you're thinking of font-lock, then it uses with-silent-modifications. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:46:54 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:46:54 +0000 Received: from localhost ([127.0.0.1]:40248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCty-0004QK-GE for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:46:54 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:35880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCtw-0004Q6-4x for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:46:52 -0400 Received: by mail-wm0-f51.google.com with SMTP id 127so2639819wmu.1 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 08:46:52 -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=bjPDJrfP90mtIHSPJfpC3Q/+0k5z3PltSBZpYy5aE8k=; b=QZkc7soyJLV+T6Y4gfJ31CODfwZAyrAE+eG5PokKv/j33pciO68tJlX880OD+va6KQ cE/5Dl3aiq8SrTgZJ6r2v1ohnCl9tzpJbDqkg0R9qu92oqKtQHH1Z8bG4ULfqVN/zG8M Bq7ZFlmPjJFH796FzDLH05TIRYTDDitE+WlQF6fURNsVV6ocgSloBzZiM6h3HpVEEvb+ YDcXHR4Fy7umNUVjgER+M3sBQBmT1DuUzw58HpFnzskUEfVUFaIM33zZxNwaYyOxwP+g 3P8mlPjnJyoMgGTJO1EqwtTnKeLZUcVulHBe4H9/5YhfGQWUqFtVJ/BRWTh3OigofbHL hDoA== 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=bjPDJrfP90mtIHSPJfpC3Q/+0k5z3PltSBZpYy5aE8k=; b=QRrZWzpWToJSB1bCkAapSzFV4YUxMfb72nE3ooGYSOUitH825H2757chXOt+Cb9r4d METVFWQt1U8/c6g0Jzs8h7h6WytiG7HP3Hu5mwlvTHIWleTjKWuBOCNdVug51RRQMgkg wAQD7pM2BwmTmiHfwCKv6Ryz0QpdfzHg7pi1KBbExlW8eol/YN38uCtxAheO/z2KRaeu R0DfmaxejINTQWTLtqrxTrEoujjwZdiH8siaUD2TV0Jr/k8N9/8TXje09rJg3JBskddM qLVIjcLdwoE4MCgCmGyYKNYZFpagcF4dfbyeEEfKpU/y8KthacHNdZTurMehzZPtBaHf u2TA== X-Gm-Message-State: AD7BkJK/gS7S3OzKB8QxWm/OaQYv0yBl1kdLDRFQ06ffkVawtAik47/zRfhwaBmoWLb+xQ== X-Received: by 10.28.96.197 with SMTP id u188mr6887824wmb.26.1459093606645; Sun, 27 Mar 2016 08:46:46 -0700 (PDT) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id c128sm6268939wma.11.2016.03.27.08.46.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 08:46:46 -0700 (PDT) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: =?UTF-8?Q?=c3=93scar_Fuentes?= 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> From: Dmitry Gutov Message-ID: <5ae788d4-42cc-e1f9-dfa4-c25ff2acc10f@yandex.ru> Date: Sun, 27 Mar 2016 18:46:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <87egawaq84.fsf@wanadoo.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03/27/2016 06:35 PM, Óscar Fuentes wrote: > Dmitry, it would be absolutely glorious if we ever find a md5 collision > among a piece of text and the result of applying fill-paragraph to it. I > would demand to be credited by the feat :-) Glorious or not, such an occasion would likely go unnoticed, and could result in the user not having their latest changes saved to disk. The only thing they would remember is that Emacs didn't work as expected, and your choice of the algorithm would go uncredited. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:46:59 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:47:00 +0000 Received: from localhost ([127.0.0.1]:40251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCu3-0004Qb-Nn for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:46:59 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:60986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCu2-0004QU-UJ for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:46:59 -0400 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 1akCtx-0002qt-PV; Sun, 27 Mar 2016 17:46:57 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEX9/fjg4NG7xqmitKQ3 Aww0FyCKmJgxBw+DT0VoMDHP1spUAA/////+//7v7diZblILeSygAAABlUlEQVQ4jd3Sv0vDQBQH 8KggDmnpLdIpduwiHYogQXSJdFcuFgeXwtG6xzN/QdNVVKgBaRFEMusgWWJHaTt0EIegnZzSFroY F+v9ahsVce8bQu59eLkL95Waf5Q0K+BJpOI+X3nr0DgPODRGtFY5rGFSR3IEhmzkCbM6iAAbab1z MP0I0JFnLKoWATLilUX/GHQjMPSXSM+A5HEBgDyFUapM+xDumQ4AiQmEVoX3IdwnoPgCQsvKYcz6 UKUgcyD9Uyxg16EQCAjDM4ihnrfyJdWpK0qXQiqZ6Wx1SnPm5aKOUMEB/VhcCiQv85keDTLLxStz 51ovFtQ6ULr9fiA1B2SDiq1hfig9q9I9AIEXctKqq+U4oCm0klbVdW81CmQPCnXy6+QGXyu267qa hg3SR9ksOy692gYZYGIghMSnehTaHFxtewKKzMJwI+RuAjGeEi9tT6BAoTeOT/uDyb2A3jRXD0wE JKKBe6RH5lD7nsR5IhRQzf8R0YWqTWHT/5XdQfXkDR2O+wLYcmXDA/Sl9U/aZx2+ACk4Di7693OD AAAAAElFTkSuQmCC Date: Sun, 27 Mar 2016 17:46:53 +0200 In-Reply-To: <83lh54ynol.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Mar 2016 17:56:26 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , jwiegley@gmail.com, j_k_v@ro.ru, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> + (when (and (not (string= h "")) >> + (string= h (secure-hash 'md5 (current-buffer)))) >> + (set-buffer-modified-p nil))) > > Thanks, but I'm not sure computing the hash is enough: the functions > involved in refilling can change text properties, so the test should > also account for that. True. Do we have an efficient way to get the text properties, too? (I mean, without doing a `buffer-substring'...) Hm... looking at `secure-hash', it seems incredibly inefficient. (Unless I'm misreading the code.) All the coding system conversion stuff is completely irrelevant for this usage... What we basically need is a fast hashing function for the buffer, including text properties. So it would basically do: 1) move the gap out of the way 2) call the hashing function on the buffer contents c) call the hashing function on the text properties 4) hash them together This should be really fast, I think? If the text properties are available in a fashion where we can do some hashing on them without copying them around a lot. And I know nothing about how text properties are represented. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:51:03 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:51:03 +0000 Received: from localhost ([127.0.0.1]:40256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCxz-0004WY-81 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:51:03 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:32798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCxx-0004W9-Fp for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:51:01 -0400 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 1akCxu-0002s4-Qm; Sun, 27 Mar 2016 17:51:00 +0200 From: Lars Magne Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83927858-0341-096f-b7e2-1322489efda8@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEX9/fjg4NG7xqmitKQ3 Aww0FyCKmJgxBw+DT0VoMDHP1spUAA/////+//7v7diZblILeSygAAABlUlEQVQ4jd3Sv0vDQBQH 8KggDmnpLdIpduwiHYogQXSJdFcuFgeXwtG6xzN/QdNVVKgBaRFEMusgWWJHaTt0EIegnZzSFroY F+v9ahsVce8bQu59eLkL95Waf5Q0K+BJpOI+X3nr0DgPODRGtFY5rGFSR3IEhmzkCbM6iAAbab1z MP0I0JFnLKoWATLilUX/GHQjMPSXSM+A5HEBgDyFUapM+xDumQ4AiQmEVoX3IdwnoPgCQsvKYcz6 UKUgcyD9Uyxg16EQCAjDM4ihnrfyJdWpK0qXQiqZ6Wx1SnPm5aKOUMEB/VhcCiQv85keDTLLxStz 51ovFtQ6ULr9fiA1B2SDiq1hfig9q9I9AIEXctKqq+U4oCm0klbVdW81CmQPCnXy6+QGXyu267qa hg3SR9ksOy692gYZYGIghMSnehTaHFxtewKKzMJwI+RuAjGeEi9tT6BAoTeOT/uDyb2A3jRXD0wE JKKBe6RH5lD7nsR5IhRQzf8R0YWqTWHT/5XdQfXkDR2O+wLYcmXDA/Sl9U/aZx2+ACk4Di7693OD AAAAAElFTkSuQmCC Date: Sun, 27 Mar 2016 17:50:58 +0200 In-Reply-To: <83927858-0341-096f-b7e2-1322489efda8@yandex.ru> (Dmitry Gutov's message of "Sun, 27 Mar 2016 18:42:35 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Dmitry Gutov writes: > And yet, why would we allow such possibility? String comparison is > plenty fast already. Comparison is fast, but making a copy of a buffer (or its contents) isn't. (If the buffer is large, that is.) If you've loaded a 2GB file and hit `M-q' on a line, it would be rather awkward if that made Emacs allocate an additional 2GB of data. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:52:42 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:52:42 +0000 Received: from localhost ([127.0.0.1]:40260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCza-0004Yn-JU for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:52:42 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:56295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akCzZ-0004Yc-Ae for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:52:41 -0400 Received: from smtp.movistar.es (smtp11.acens.net [86.109.99.135]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id AE4C243E2; Sun, 27 Mar 2016 17:52:35 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0202.56F801C3.0150, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BC428E034CC3AC; Sun, 27 Mar 2016 15:52:51 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 17:52:34 +0200 In-Reply-To: <37404e91-f1bf-072c-ff05-a3070391003e@yandex.ru> (Dmitry Gutov's message of "Sun, 27 Mar 2016 18:42:43 +0300") Message-ID: <87a8ljc3zx.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Dmitry Gutov writes: > On 03/27/2016 06:28 PM, =C3=93scar Fuentes wrote: > >> The docs say: >> >> >> This shows two dashes (=E2=80=98--=E2=80=99) if the buffer displayed i= n the window has >> the same contents as the corresponding file on the disk; i.e., if the >> buffer is unmodified. > > That might be a documentation bug. Switch to an unmodified buffer. > Type `a', and then backspace. What do you see in the status? When you type `a', you changed the buffer. Checking that your subsequent actions gives a result that is identical to the saved file is something that would be nice to have, but I guess that few users would think that it is a reasonable requirement. OTOH, `undo' clears the `modified' flag. >> AFAIK, a file-visiting buffer is not marked as modified when text >> properties are applied to it. > > It is. If you're thinking of font-lock, then it uses > with-silent-modifications. And why it does use with-silent-modifications? Is there a case where the user is benefited from marking the buffer as modified after applying text properties? From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:53:28 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:53:28 +0000 Received: from localhost ([127.0.0.1]:40264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akD0J-0004a8-Sj for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:53:28 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:32813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akD0I-0004a1-OR for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:53:27 -0400 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 1akD0F-0002u4-T9; Sun, 27 Mar 2016 17:53:25 +0200 From: Lars Magne Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEX9/fjg4NG7xqmitKQ3 Aww0FyCKmJgxBw+DT0VoMDHP1spUAA/////+//7v7diZblILeSygAAABlUlEQVQ4jd3Sv0vDQBQH 8KggDmnpLdIpduwiHYogQXSJdFcuFgeXwtG6xzN/QdNVVKgBaRFEMusgWWJHaTt0EIegnZzSFroY F+v9ahsVce8bQu59eLkL95Waf5Q0K+BJpOI+X3nr0DgPODRGtFY5rGFSR3IEhmzkCbM6iAAbab1z MP0I0JFnLKoWATLilUX/GHQjMPSXSM+A5HEBgDyFUapM+xDumQ4AiQmEVoX3IdwnoPgCQsvKYcz6 UKUgcyD9Uyxg16EQCAjDM4ihnrfyJdWpK0qXQiqZ6Wx1SnPm5aKOUMEB/VhcCiQv85keDTLLxStz 51ovFtQ6ULr9fiA1B2SDiq1hfig9q9I9AIEXctKqq+U4oCm0klbVdW81CmQPCnXy6+QGXyu267qa hg3SR9ksOy692gYZYGIghMSnehTaHFxtewKKzMJwI+RuAjGeEi9tT6BAoTeOT/uDyb2A3jRXD0wE JKKBe6RH5lD7nsR5IhRQzf8R0YWqTWHT/5XdQfXkDR2O+wLYcmXDA/Sl9U/aZx2+ACk4Di7693OD AAAAAElFTkSuQmCC Date: Sun, 27 Mar 2016 17:53:23 +0200 In-Reply-To: <5ae788d4-42cc-e1f9-dfa4-c25ff2acc10f@yandex.ru> (Dmitry Gutov's message of "Sun, 27 Mar 2016 18:46:44 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Dmitry Gutov writes: > Glorious or not, such an occasion would likely go unnoticed, and could > result in the user not having their latest changes saved to disk. I look forward to seeing you visiting the git mailing list and starting to agitate for not using sha-1 hashes as object identifiers in git, because it might obviously lose data if you happen to get collisions. Have fun. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:57:22 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:57:22 +0000 Received: from localhost ([127.0.0.1]:40268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akD46-0004fd-Cw for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:57:22 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:32878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akD44-0004fV-ES for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:57:21 -0400 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 1akD41-0002vC-F7; Sun, 27 Mar 2016 17:57:19 +0200 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?=D3scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEX9/fjg4NG7xqmitKQ3 Aww0FyCKmJgxBw+DT0VoMDHP1spUAA/////+//7v7diZblILeSygAAABlUlEQVQ4jd3Sv0vDQBQH 8KggDmnpLdIpduwiHYogQXSJdFcuFgeXwtG6xzN/QdNVVKgBaRFEMusgWWJHaTt0EIegnZzSFroY F+v9ahsVce8bQu59eLkL95Waf5Q0K+BJpOI+X3nr0DgPODRGtFY5rGFSR3IEhmzkCbM6iAAbab1z MP0I0JFnLKoWATLilUX/GHQjMPSXSM+A5HEBgDyFUapM+xDumQ4AiQmEVoX3IdwnoPgCQsvKYcz6 UKUgcyD9Uyxg16EQCAjDM4ihnrfyJdWpK0qXQiqZ6Wx1SnPm5aKOUMEB/VhcCiQv85keDTLLxStz 51ovFtQ6ULr9fiA1B2SDiq1hfig9q9I9AIEXctKqq+U4oCm0klbVdW81CmQPCnXy6+QGXyu267qa hg3SR9ksOy692gYZYGIghMSnehTaHFxtewKKzMJwI+RuAjGeEi9tT6BAoTeOT/uDyb2A3jRXD0wE JKKBe6RH5lD7nsR5IhRQzf8R0YWqTWHT/5XdQfXkDR2O+wLYcmXDA/Sl9U/aZx2+ACk4Di7693OD AAAAAElFTkSuQmCC Date: Sun, 27 Mar 2016 17:57:17 +0200 In-Reply-To: <87a8ljc3zx.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Sun, 27 Mar 2016 17:52:34 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) =D3scar Fuentes writes: > When you type `a', you changed the buffer. Checking that your subsequent > actions gives a result that is identical to the saved file is something > that would be nice to have, but I guess that few users would think that > it is a reasonable requirement. I think that would be a very nice feature, though. Like, if Emacs computed the hash of the buffer when you loaded it, and then checks again every time you edit something, and uses that for the "buffer changed" marker. :-) It's probably unrealistically slow, though. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 11:59:21 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 15:59:21 +0000 Received: from localhost ([127.0.0.1]:40272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akD60-0004iV-PM for submit@debbugs.gnu.org; Sun, 27 Mar 2016 11:59:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48761) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akD5y-0004iJ-SG for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:59:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akD5q-0006E1-N5 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 11:59:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akD5q-0006Dx-Jh; Sun, 27 Mar 2016 11:59:10 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3361 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akD5p-00086N-Ni; Sun, 27 Mar 2016 11:59:10 -0400 Date: Sun, 27 Mar 2016 18:58:48 +0300 Message-Id: <83bn5zzzd3.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?=C3=93scar?= Fuentes In-reply-to: <87io08aqhr.fsf@wanadoo.es> (message from =?utf-8?Q?=C3=93sca?= =?utf-8?Q?r?= Fuentes on Sun, 27 Mar 2016 17:29:36 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: jwiegley@gmail.com, j_k_v@ro.ru, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Óscar Fuentes > Cc: jwiegley@gmail.com, j_k_v@ro.ru, 13949@debbugs.gnu.org > Date: Sun, 27 Mar 2016 17:29:36 +0200 > > AFAIK, a file-visiting buffer is not marked as modified when text > properties are applied to it. This makes sense, because text properties > are not part of the contents of the corresponding file. It is, and they are. Here, try this: emacs -Q C-x C-f README RET M-: (put-text-property 1 10 'myprop 'foo) RET Then look at the buffer-modified indication. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:05:56 2016 Received: (at submit) by debbugs.gnu.org; 27 Mar 2016 16:05:56 +0000 Received: from localhost ([127.0.0.1]:40283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDCN-0004v3-UN for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDCM-0004uj-Iz for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDCG-0007TV-Qi for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDCG-0007TR-NC for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDCF-0000IG-P9 for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:05:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDCC-0007TD-GA for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:05:47 -0400 Received: from plane.gmane.org ([80.91.229.3]:53903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDCC-0007T5-7l for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:05:44 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1akDCA-0005dg-Mm for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 18:05:43 +0200 Received: from 151.red-79-153-146.dynamicip.rima-tde.net ([79.153.146.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2016 18:05:42 +0200 Received: from ofv by 151.red-79-153-146.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2016 18:05:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: =?utf-8?Q?=C3=93scar_Fuentes?= Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Sun, 27 Mar 2016 18:05:36 +0200 Lines: 23 Message-ID: <8737rbc3e7.fsf@wanadoo.es> 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 151.red-79-153-146.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) Cancel-Lock: sha1:+YT4i6pJ+5zIlLzqYI9iwjbH+6c= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) Eli Zaretskii writes: >> AFAIK, a file-visiting buffer is not marked as modified when text >> properties are applied to it. This makes sense, because text properties >> are not part of the contents of the corresponding file. > > It is, and they are. Here, try this: > > emacs -Q > C-x C-f README RET > M-: (put-text-property 1 10 'myprop 'foo) RET > > Then look at the buffer-modified indication. Sorry, but AFAIK if some feature does this without a with-silent-modifications wrapping it, a bug report would is in order, right? Again, the question nobody dares to answer: is there a legit case where the user benefits from marking the buffer as modified after applying or changing text properties? >From the lack of response so far, I guess that the answer is "no". From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:05:10 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:05:10 +0000 Received: from localhost ([127.0.0.1]:40278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDBe-0004sw-EI for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDBZ-0004rz-Mx for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDBQ-0007L4-WF for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:05:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57586) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDBQ-0007L0-Si; Sun, 27 Mar 2016 12:04:56 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3364 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akDBQ-0004F8-2s; Sun, 27 Mar 2016 12:04:56 -0400 Date: Sun, 27 Mar 2016 19:04:34 +0300 Message-Id: <83a8ljzz3h.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Sun, 27 Mar 2016 17:46:53 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, jwiegley@gmail.com, j_k_v@ro.ru, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Cc: Óscar Fuentes , jwiegley@gmail.com, > j_k_v@ro.ru, 13949@debbugs.gnu.org > Date: Sun, 27 Mar 2016 17:46:53 +0200 > > 1) move the gap out of the way This will call memmove to move a potentially large chunk of text. Why not just hash the two parts separately? From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:08:24 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:08:24 +0000 Received: from localhost ([127.0.0.1]:40289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDEm-000527-Ef for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:08:24 -0400 Received: from huan1.mail.rambler.ru ([81.19.66.27]:37244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDEk-00051s-KF for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:08:23 -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=2U6uw9R5PSR6JgnEQUM0WyBAjy/iM1NpsSVAclqi9gM=; b=uM/DZGWz704eSOfYEIjKJghaUXVYx7Qqb9geH22IZbyBrAc65M4Ur+DGurt25xt8t9BY9sQ4M9NEtnScb87jsReN/6nkib/6IXSbQBf91nfNku20O0wfzR7PDcT+h6sMx91naz1xjj7Kh/79Mmw/gYh8hxOtTaEd1kxQYHrABiY=; Received: from [UNAVAILABLE] ([93.204.110.126]:30941 helo=[192.168.3.203]) by huan1.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1akDEf-00083G-7k; Sun, 27 Mar 2016 19:08:17 +0300 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: Lars Magne Ingebrigtsen , Dmitry Gutov 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> From: Jaakov Message-ID: <56F80570.3090909@ro.ru> Date: Sun, 27 Mar 2016 18:08:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/93.204.110.126 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: =?UTF-8?Q?=c3=93scar_Fuentes?= , John Wiegley , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > It's less likely that the before/after `M-q' strings hash to the same > md5 than cosmic rays reprogramming your Emacs into vi, so: Users' texts are not completely random, but highly correlated. Therefore, the argument about unlikeliness (which might hold for equidistributed texts, for each length) does not apply. If the above patch stays upstream, I'm going to switch from emacs to something else and advise others to do so. Really. Please don't cc me any more. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:11:55 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:11:55 +0000 Received: from localhost ([127.0.0.1]:40293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDIA-00059m-UQ for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:11:55 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:33092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDI8-00059e-UE for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:11:53 -0400 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 1akDI4-00030i-2s; Sun, 27 Mar 2016 18:11:52 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> 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 Date: Sun, 27 Mar 2016 18:11:47 +0200 In-Reply-To: <83a8ljzz3h.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Mar 2016 19:04:34 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, jwiegley@gmail.com, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > This will call memmove to move a potentially large chunk of text. Why > not just hash the two parts separately? Yeah, that's true. What about the text property representation -- can that easily be hashed, do you think? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:12:34 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:12:34 +0000 Received: from localhost ([127.0.0.1]:40297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDIo-0005B1-5a for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:12:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDIm-0005Aq-Pq for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:12:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDIe-0000RL-I3 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:12:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDIe-0000RH-Ea; Sun, 27 Mar 2016 12:12:24 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3373 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akDId-0004w9-Qj; Sun, 27 Mar 2016 12:12:24 -0400 Date: Sun, 27 Mar 2016 19:12:02 +0300 Message-Id: <837fgnzyr1.fsf@gnu.org> From: Eli Zaretskii To: =?iso-8859-1?Q?=D3scar?= Fuentes In-reply-to: <8737rbc3e7.fsf@wanadoo.es> (message from =?iso-8859-1?Q?=D3s?= =?iso-8859-1?Q?car?= Fuentes on Sun, 27 Mar 2016 18:05:36 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Óscar Fuentes > Date: Sun, 27 Mar 2016 18:05:36 +0200 > > > emacs -Q > > C-x C-f README RET > > M-: (put-text-property 1 10 'myprop 'foo) RET > > > > Then look at the buffer-modified indication. > > Sorry, but AFAIK if some feature does this without a > with-silent-modifications wrapping it, a bug report would is in order, > right? No, I don't see why it should be a bug. The text property can be anything, including something that has a profound effect on how text is displayed, like 'invisible' or 'display'. > Again, the question nobody dares to answer: is there a legit case where > the user benefits from marking the buffer as modified after applying or > changing text properties? > > >From the lack of response so far, I guess that the answer is "no". This is the tail wagging the dog: we are not going to overturn a long-standing way Emacs works with text properties for the sake of a minor feature. If you really want this feature to be accepted, please find a way of doing that without any such notable effects, i.e. count changes in the text properties, if any, with the text changes. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:14:48 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:14:48 +0000 Received: from localhost ([127.0.0.1]:40301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDKy-0005EM-Hh for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:14:48 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:33148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDKw-0005EE-M5 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:14:46 -0400 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 1akDKu-00031o-9o; Sun, 27 Mar 2016 18:14:46 +0200 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?=D3scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> 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 Date: Sun, 27 Mar 2016 18:14:43 +0200 In-Reply-To: <8737rbc3e7.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Sun, 27 Mar 2016 18:05:36 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) =D3scar Fuentes writes: > Again, the question nobody dares to answer: is there a legit case where > the user benefits from marking the buffer as modified after applying or > changing text properties? > > From the lack of response so far, I guess that the answer is "no". Some modes support generating various "rich text" modes based on text properties. Those modes are rare, though. I think we probably could say that those modes should "do something special" and make Emacs, by default, not care about text properties for the "buffer changed" thing. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:18:32 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:18:32 +0000 Received: from localhost ([127.0.0.1]:40315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDOa-0005LY-Fq for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:18:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDOZ-0005LL-CM for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:18:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDOQ-00021z-Gs for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:18:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57846) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDOQ-00021v-DV; Sun, 27 Mar 2016 12:18:22 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3380 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akDOP-0005cR-FI; Sun, 27 Mar 2016 12:18:21 -0400 Date: Sun, 27 Mar 2016 19:18:00 +0300 Message-Id: <8360w7zyh3.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Sun, 27 Mar 2016 18:11:47 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, jwiegley@gmail.com, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Cc: ofv@wanadoo.es, jwiegley@gmail.com, 13949@debbugs.gnu.org > Date: Sun, 27 Mar 2016 18:11:47 +0200 > > What about the text property representation -- can that easily be > hashed, do you think? One could hack something together along the lines of compare_string_intervals and intervals_equal, I think. That is, traverse the tree as they do, and compute the hash while at that. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:22:12 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:22:12 +0000 Received: from localhost ([127.0.0.1]:40319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDS4-0005R0-W5 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:22:12 -0400 Received: from smtp09.acens.net ([86.109.99.133]:56785 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDRz-0005QS-WE for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:22:07 -0400 X-CTCH-RefID: str=0001.0A0B0204.56F808A5.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56E354CE01049138; Sun, 27 Mar 2016 16:21:57 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Lars Magne Ingebrigtsen Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 18:21:55 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 27 Mar 2016 17:57:17 +0200") Message-ID: <87vb47ao2k.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Magne Ingebrigtsen writes: > =C3=93scar Fuentes writes: > >> When you type `a', you changed the buffer. Checking that your subsequent >> actions gives a result that is identical to the saved file is something >> that would be nice to have, but I guess that few users would think that >> it is a reasonable requirement. > > I think that would be a very nice feature, though. Like, if Emacs > computed the hash of the buffer when you loaded it, and then checks > again every time you edit something, and uses that for the "buffer > changed" marker. :-) Interesting... :-) > It's probably unrealistically slow, though. 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. Then, the hash would be calculated on a idle timer that is fired after a command that changes the contents... It is doable, moreover if the current hash function is so inefficient as you say. MD5 is rated at more than a hundred MB/s on not-so-new hardware. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:28:48 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:28:48 +0000 Received: from localhost ([127.0.0.1]:40323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDYW-0005aD-3u for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:28:48 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:33382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDYV-0005a6-8w for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:28:47 -0400 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 1akDYS-00037m-CK; Sun, 27 Mar 2016 18:28:46 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> 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 Date: Sun, 27 Mar 2016 18:28:43 +0200 In-Reply-To: <8360w7zyh3.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Mar 2016 19:18:00 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, jwiegley@gmail.com, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > One could hack something together along the lines of > compare_string_intervals and intervals_equal, I think. That is, > traverse the tree as they do, and compute the hash while at that. *peruses code* I see. Looking at this, and looking at the sha1 reference for all of two minutes, it looks like we could create a new C-level function called something like hash_buffer that would look basically like sha1_init_ctx sha1_process_bytes(first_part_of_buffer, len) sha1_process_bytes(last_part_of_buffer, len) for iterate_over_all_intervals sha1_process_bytes(interval, len) sha1_finish_ctx and there you have it. A hashing function that would not allocate anything much, and it should be fast enough even in huge buffers for `M-q'. I think. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:33:43 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:33:43 +0000 Received: from localhost ([127.0.0.1]:40327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDdH-0007L0-M7 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:33:43 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:33462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDdG-0007Ks-2J for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:33:42 -0400 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 1akDd9-00039P-Jj; Sun, 27 Mar 2016 18:33:41 +0200 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?=D3scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> 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 Date: Sun, 27 Mar 2016 18:33:35 +0200 In-Reply-To: <87vb47ao2k.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Sun, 27 Mar 2016 18:21:55 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) =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. :-) > Then, the hash would be calculated on a idle timer that is fired after > a command that changes the contents... 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. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:37:34 2016 Received: (at submit) by debbugs.gnu.org; 27 Mar 2016 16:37:34 +0000 Received: from localhost ([127.0.0.1]:40331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDh0-0007QD-6L for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:37:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDgy-0007Py-L5 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:37:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDgs-0005Un-Qi for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:37:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDgs-0005Uj-Nd for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:37:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDgr-0005jO-Nr for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:37:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDgm-0005Sy-O4 for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:37:25 -0400 Received: from plane.gmane.org ([80.91.229.3]:54742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDgm-0005Rl-Gq for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 12:37:20 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1akDgk-0001lO-Li for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 18:37:18 +0200 Received: from 151.red-79-153-146.dynamicip.rima-tde.net ([79.153.146.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2016 18:37:18 +0200 Received: from ofv by 151.red-79-153-146.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2016 18:37:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: =?utf-8?Q?=C3=93scar_Fuentes?= Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Sun, 27 Mar 2016 18:37:10 +0200 Lines: 28 Message-ID: <87r3evand5.fsf@wanadoo.es> 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> <837fgnzyr1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 151.red-79-153-146.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) Cancel-Lock: sha1:Mqux6RLr4M5nHuEkgTT9LbVzY7s= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) Eli Zaretskii writes: >> Again, the question nobody dares to answer: is there a legit case where >> the user benefits from marking the buffer as modified after applying or >> changing text properties? >> >> >From the lack of response so far, I guess that the answer is "no". > > This is the tail wagging the dog: we are not going to overturn a > long-standing way Emacs works with text properties for the sake of a > minor feature. "minor" is your judgement. And so far there is zero evidence that this change could cause undesired effects. So we have users suffering this bug (yes, it is obvious to some of us that it is a bug) and, OTOH, we have FUD. > If you really want this feature to be accepted, Sorry Eli, but as much as I appreciate your opinions, I'm not submitting the feature for *your* approval. You are not the only one that can approve (or reject) the patch (once we have one.) > please find a way of doing that without any such notable effects, i.e. > count changes in the text properties, if any, with the text changes. You are decided to block a solution for this issue, just because. Got it. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:38:12 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:38:12 +0000 Received: from localhost ([127.0.0.1]:40336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDhc-0007RZ-FH for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:38:12 -0400 Received: from relaycp02.dominioabsoluto.net ([217.116.26.74]:36682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDha-0007RG-Lz for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:38:11 -0400 Received: from smtp.movistar.es (smtp11.acens.net [86.109.99.135]) by relaycp02.dominioabsoluto.net (Postfix) with ESMTP id BA8F8D23A1 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 18:38:04 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0202.56F80C6C.015E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BC428E034D27B9 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 16:38:20 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: 13949@debbugs.gnu.org Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> <837fgnzyr1.fsf@gnu.org> Date: Sun, 27 Mar 2016 18:38:03 +0200 In-Reply-To: <837fgnzyr1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Mar 2016 19:12:02 +0300") Message-ID: <87mvpjanbo.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> Again, the question nobody dares to answer: is there a legit case where >> the user benefits from marking the buffer as modified after applying or >> changing text properties? >> >> >From the lack of response so far, I guess that the answer is "no". > > This is the tail wagging the dog: we are not going to overturn a > long-standing way Emacs works with text properties for the sake of a > minor feature. "minor" is your judgement. And so far there is zero evidence that this change could cause undesired effects. So we have users suffering this bug (yes, it is obvious to some of us that it is a bug) and, OTOH, we have FUD. > If you really want this feature to be accepted, Sorry Eli, but as much as I appreciate your opinions, I'm not submitting the feature for *your* approval. You are not the only one that can approve (or reject) the patch (once we have one.) > please find a way of doing that without any such notable effects, i.e. > count changes in the text properties, if any, with the text changes. You are decided to block a solution for this issue, just because. Got it. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:46:40 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:46:40 +0000 Received: from localhost ([127.0.0.1]:40352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDpn-0007e5-2E for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:46:40 -0400 Received: from smtp21.acens.net ([86.109.99.145]:26999 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDpi-0007dn-Ds for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:46:38 -0400 X-CTCH-RefID: str=0001.0A0B0203.56F80E64.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56B309D3039E665D; Sun, 27 Mar 2016 16:46:28 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Lars Magne Ingebrigtsen Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 18:46:27 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 27 Mar 2016 18:33:35 +0200") Message-ID: <87io07amxo.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Magne Ingebrigtsen writes: > =C3=93scar 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. >> Then, the hash would be calculated on a idle timer that is fired after >> a command that changes the contents... > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:51:29 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:51:29 +0000 Received: from localhost ([127.0.0.1]:40356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDuT-0007kp-5c for submit@debbugs.gnu.org; Sun, 27 Mar 2016 12:51:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57159) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akDuR-0007ke-Up for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:51:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akDuJ-0007lz-NH for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 12:51:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akDuJ-0007lv-Jl; Sun, 27 Mar 2016 12:51:19 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3399 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akDuJ-0004Fv-03; Sun, 27 Mar 2016 12:51:19 -0400 Date: Sun, 27 Mar 2016 19:50:57 +0300 Message-Id: <8337rbzwy6.fsf@gnu.org> From: Eli Zaretskii To: =?iso-8859-1?Q?=D3scar?= Fuentes In-reply-to: <87r3evand5.fsf@wanadoo.es> (message from =?iso-8859-1?Q?=D3s?= =?iso-8859-1?Q?car?= Fuentes on Sun, 27 Mar 2016 18:37:10 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> <837fgnzyr1.fsf@gnu.org> <87r3evand5.fsf@wanadoo.es> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Óscar Fuentes > Date: Sun, 27 Mar 2016 18:37:10 +0200 > > Eli Zaretskii writes: > > >> Again, the question nobody dares to answer: is there a legit case where > >> the user benefits from marking the buffer as modified after applying or > >> changing text properties? > >> > >> >From the lack of response so far, I guess that the answer is "no". > > > > This is the tail wagging the dog: we are not going to overturn a > > long-standing way Emacs works with text properties for the sake of a > > minor feature. > > "minor" is your judgement. You could try making a case for it not being minor, maybe you will be able to convince. For now, I don't see how it could be anything but minor, or else we would have changed it long ago. > And so far there is zero evidence that this change could cause > undesired effects. That's irrelevant. It would be irresponsible for us to change such basic aspects of Emacs operation at this point in Emacs history. We have been burnt with much less significant backward-incompatible changes. > > If you really want this feature to be accepted, > > Sorry Eli, but as much as I appreciate your opinions, I'm not submitting > the feature for *your* approval. You are not the only one that can > approve (or reject) the patch (once we have one.) I'm not the only one, but I'm one of those you need to convince. > > please find a way of doing that without any such notable effects, i.e. > > count changes in the text properties, if any, with the text changes. > > You are decided to block a solution for this issue, just because. Got > it. That's a nasty, unfair way of putting things, and you know it. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 12:58:29 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 16:58:29 +0000 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 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 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 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?=D3scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> 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 Date: Sun, 27 Mar 2016 18:58:21 +0200 In-Reply-To: <87io07amxo.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Sun, 27 Mar 2016 18:46:27 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) =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 From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 13:00:51 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 17:00:51 +0000 Received: from localhost ([127.0.0.1]:40368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akE3X-0007zE-Jw for submit@debbugs.gnu.org; Sun, 27 Mar 2016 13:00:51 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:33813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akE3V-0007z7-Sa for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 13:00:50 -0400 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 1akE3T-0003IN-9t; Sun, 27 Mar 2016 19:00:49 +0200 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?=D3scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> <837fgnzyr1.fsf@gnu.org> <87mvpjanbo.fsf@wanadoo.es> 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 Date: Sun, 27 Mar 2016 19:00:46 +0200 In-Reply-To: <87mvpjanbo.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Sun, 27 Mar 2016 18:38:03 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) =D3scar Fuentes writes: > "minor" is your judgement. And so far there is zero evidence that this > change could cause undesired effects. So we have users suffering this > bug (yes, it is obvious to some of us that it is a bug) and, OTOH, we > have FUD. I think you're being somewhat unfair here. None of this is obvious, and we're just talking about how to make Emacs slightly better. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 13:30:46 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 17:30:46 +0000 Received: from localhost ([127.0.0.1]:40378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akEWU-0000FB-AM for submit@debbugs.gnu.org; Sun, 27 Mar 2016 13:30:46 -0400 Received: from smtp10.acens.net ([86.109.99.134]:19597 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akEWR-0000Ex-Q2 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 13:30:44 -0400 X-CTCH-RefID: str=0001.0A0B0201.56F818BD.0199, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56F5ABE50014F204; Sun, 27 Mar 2016 17:30:37 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> <837fgnzyr1.fsf@gnu.org> <87r3evand5.fsf@wanadoo.es> <8337rbzwy6.fsf@gnu.org> Date: Sun, 27 Mar 2016 19:30:36 +0200 In-Reply-To: <8337rbzwy6.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 27 Mar 2016 19:50:57 +0300") Message-ID: <87a8ljakw3.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli Zaretskii writes: >> "minor" is your judgement. > > You could try making a case for it not being minor, maybe you will be > able to convince. For now, I don't see how it could be anything but > minor, or else we would have changed it long ago. See this bug report and its duplicateds. It is not a data-loss bug, but something that can be a constant annoyance to some users. It occurred to me at least two times to use M-q on comments on some C++ header, see no changes, proceed with other edits elsewhere on the project, and much later do `C-x s ! M-x compile' and see how the build compiled files that shouldn't be affected by my edits, which, apart from the waste of time on the extended build, caused more time to be wasted on investigating the cause. Since I aware of the problem, if I use M-q on a source file, I need to use `C-x s d' to see a diff and, if the diff is empty, use undo to restore the modified flag. >> And so far there is zero evidence that this change could cause >> undesired effects. > > That's irrelevant. It would be irresponsible for us to change such > basic aspects of Emacs operation at this point in Emacs history. We > have been burnt with much less significant backward-incompatible > changes. This is a recipe for changing *nothing* that is older than some threshold, isn't it? And we are talking about fill-paragraph here, not about some core data structure. Apart from the fact that marking the buffer as modified when text properties are changed is wrong in principle (otherwise, why don't mark as modified the file-visiting buffers as soon as some text properties are applied when the major/minor modes are enabled?) [snip] From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 13:52:08 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 17:52:08 +0000 Received: from localhost ([127.0.0.1]:40391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akErA-0000kj-Bn for submit@debbugs.gnu.org; Sun, 27 Mar 2016 13:52:08 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akEr9-0000kY-C7 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 13:52:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akEqz-0002fh-Vr for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 13:52:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akEqz-0002fd-SS; Sun, 27 Mar 2016 13:51:57 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3435 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akEqz-00080p-7u; Sun, 27 Mar 2016 13:51:57 -0400 Date: Sun, 27 Mar 2016 20:51:35 +0300 Message-Id: <83wponyfko.fsf@gnu.org> From: Eli Zaretskii To: =?iso-8859-1?Q?=D3scar?= Fuentes In-reply-to: <87a8ljakw3.fsf@wanadoo.es> (message from =?iso-8859-1?Q?=D3s?= =?iso-8859-1?Q?car?= Fuentes on Sun, 27 Mar 2016 19:30:36 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <87io08aqhr.fsf@wanadoo.es> <83bn5zzzd3.fsf@gnu.org> <8737rbc3e7.fsf@wanadoo.es> <837fgnzyr1.fsf@gnu.org> <87r3evand5.fsf@wanadoo.es> <8337rbzwy6.fsf@gnu.org> <87a8ljakw3.fsf@wanadoo.es> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Óscar Fuentes > Cc: 13949@debbugs.gnu.org > Date: Sun, 27 Mar 2016 19:30:36 +0200 > > It occurred to me at least two times to use M-q on comments on some C++ > header, see no changes, proceed with other edits elsewhere on the > project, and much later do `C-x s ! M-x compile' and see how the build > compiled files that shouldn't be affected by my edits, which, apart from > the waste of time on the extended build, caused more time to be wasted > on investigating the cause. Since I aware of the problem, if I use M-q > on a source file, I need to use `C-x s d' to see a diff and, if the diff > is empty, use undo to restore the modified flag. You are describing what I consider to be a minor annoyance. I agree it's an annoyance, and I agree it would be good to have an option to prevent that, I'm just saying the annoyance is minor. > >> And so far there is zero evidence that this change could cause > >> undesired effects. > > > > That's irrelevant. It would be irresponsible for us to change such > > basic aspects of Emacs operation at this point in Emacs history. We > > have been burnt with much less significant backward-incompatible > > changes. > > This is a recipe for changing *nothing* that is older than some > threshold, isn't it? No, only those aspects that are very basic, like text properties being an integral part of buffer text. > And we are talking about fill-paragraph here, not about some core > data structure. I wasn't talking about fill-paragraph, I was talking about deciding that changes in text properties aren't considered buffer modifications. > Apart from the fact that marking the buffer as modified when text > properties are changed is wrong in principle (otherwise, why don't > mark as modified the file-visiting buffers as soon as some text > properties are applied when the major/minor modes are enabled?) I think you are only considering face properties. But text properties can be something entirely different. I gave 2 examples before, here's another, perhaps more relevant one: the 'fill-space' and 'hard' properties that are directly involved in text filling. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 14:23:11 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 18:23:11 +0000 Received: from localhost ([127.0.0.1]:40402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akFLD-0001Uh-6M for submit@debbugs.gnu.org; Sun, 27 Mar 2016 14:23:11 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25567) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akFLB-0001UV-S5 for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 14:23:10 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2RIN1qF003061 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 18:23:02 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2RIN0uv019052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 18:23:01 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2RIMxQE006943; Sun, 27 Mar 2016 18:23:00 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 27 Mar 2016 11:22:59 -0700 (PDT) From: Drew Adams To: Lars Magne Ingebrigtsen , =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= Subject: RE: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? Why do you think that? Code that uses text properties does not necessarily change other things in the buffer. I see no connection between the two. The fact that you even added "unrelated to font-locking" is perhaps a giveaway. Font-locking is the best known use of text properties. And even it does not typically involve changing other things in the buffer. Why would you expect that other code that uses text properties would be different? What's so special about font-locking in this regard? If anything, I would expect other code that uses text properties to _not_ change the buffer otherwise - just like font-lock. I say "if anything", because I don't really think there is any connection between using text properties and other buffer changes. > 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. Why? Where do you get 99%? Or even 25%? On what do you base the assumption that code that uses text properties also makes other buffer changes? What do you see as the use cases of text properties, of which 99% change the buffer otherwise? From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 14:53:54 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 18:53:54 +0000 Received: from localhost ([127.0.0.1]:40407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akFow-0002Cc-N7 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 14:53:54 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:28893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akFov-0002CP-5p for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 14:53:53 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2RIrkAD021775 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 18:53:47 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2RIriRC025688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 Mar 2016 18:53:45 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2RIrgUs005471; Sun, 27 Mar 2016 18:53:42 GMT MIME-Version: 1.0 Message-ID: <2ccf842d-57f0-44db-99c6-32421209daa7@default> Date: Sun, 27 Mar 2016 11:53:41 -0700 (PDT) From: Drew Adams To: =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= , Andreas Schwab Subject: RE: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <8760w8c6h4.fsf@wanadoo.es> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I think it is unwise to _replace_ willy-nilly the longstanding definition of buffer modification - for either users or Lisp code. Just because you think you can do something clever using hashes, that does not mean that you should, if it changes the longstanding behavior. No gratuitous loss, please. On the other hand, as I said, it might be good to expand that notion to different _kinds_ of buffer modification - not only for indication to users, but also for code. IOW, additional flexibility, why not? But replacement, no thanks. I said: There are different kinds of buffer changes. It would be good to have ways to detect these as such. The indication to users could perhaps be to use other chars for this, in addition to `*', in mode-line indicators `**' and `%*'. Any such change in the indication should be optional, e.g., controlled by a user option. There are two things that a user might want to customize here: (1) which kinds of buffer change to indicate and (2) how to indicate them. Wrt #2, a user could choose, for example, not to use different markers for different buffer changes, i.e., to always use only `*', even if s?he uses #1 to define "change" (only text changes, text and text-property changes,...) for the given buffer. (The option could be buffer-local, of course.) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 16:25:05 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 20:25:05 +0000 Received: from localhost ([127.0.0.1]:40436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akHFB-0004QJ-3I for submit@debbugs.gnu.org; Sun, 27 Mar 2016 16:25:05 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:33566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akHF9-0004Pm-Le for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 16:25:03 -0400 Received: by mail-wm0-f49.google.com with SMTP id l68so79332507wml.0 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 13:25:03 -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=Tia94WZMUGpyA/horptThuOiWSYxKUcxrIt/S8CSE60=; b=F+BSOKadX3xCQraFNBZsVqZIh12Rx1S7rYCj/7Oi0fQBAD8jyAzhravn6CSzMplUJ1 I6eiHECGgDt59itOny8ob09KNxAOvpXjvbjzWVH+aGdB6vKm3Sgz/UzRN6yteiZBVriw DTzpM98lJwx+yvtswB60APrhlJMTA0RKYbYWgHfIXNxIJxMmOkTSwy+AyGluw7Azs3dZ rqjQ+R242/I0fbwQSwXI5h+/LUqG6h8B3k7CtGz1JoV+bQ3FlccG/m8mmYKt/2Br7o7R eAYl89AV4sLUcWjpRt4Yty1iqKdra/fYz542R/BQv23wSE6ohEe0jerVMDQ+TOjzrXJ6 24GQ== 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=Tia94WZMUGpyA/horptThuOiWSYxKUcxrIt/S8CSE60=; b=cklVTxkZzqa0wxH9Be8+yyacwDblhOUSckzg4zZTem27gx5FlVzR6pjKTdmkrwrvUD 7VYosa4dmD0QFYTmN4VMluQUE6tJvrf+cGh1WhE34WjmM/SUk3hlp1mmMb2hS1ZZ/epI i2URxuKg9piYakZHNDdxr0vodMrAe4uBzwcgrGmIJSmuTha/8bJnxI8g5w87edCBUiTN avymimBspfhpzUB9+t1+0JYQYCasoAL6MaM1UZkgRprOgVvShk489TCbHI72dk1TXTZH KjmYDMnzr2MoSVGwoTFp/7QKV4WczLlWCZwJC5MmCrPADzsc8rYTmbrpQwpL55rklzmZ gChw== X-Gm-Message-State: AD7BkJKWo6X6LGY9YQg1hHgkPBnFiLJ7ixC47c4VXLmNWo8Tue6Ck7vmzDxpLzgydaNT0Q== X-Received: by 10.194.23.7 with SMTP id i7mr25235915wjf.9.1459110298116; Sun, 27 Mar 2016 13:24:58 -0700 (PDT) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id g9sm7128790wmf.15.2016.03.27.13.24.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 13:24:57 -0700 (PDT) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: Lars Magne Ingebrigtsen 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> From: Dmitry Gutov Message-ID: <6d4fb517-8fc7-6d8f-afce-9387e509a46c@yandex.ru> Date: Sun, 27 Mar 2016 23:24:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 Cc: =?UTF-8?Q?=c3=93scar_Fuentes?= , John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03/27/2016 06:53 PM, Lars Magne Ingebrigtsen wrote: > I look forward to seeing you visiting the git mailing list and starting > to agitate for not using sha-1 hashes as object identifiers in git, > because it might obviously lose data if you happen to get collisions. a) Why didn't they use md5, I wonder? b) Git has a global object index. It _can_ detect collisions, or at least that detection can be implemented. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 16:27:50 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 20:27:50 +0000 Received: from localhost ([127.0.0.1]:40440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akHHq-0004U7-FY for submit@debbugs.gnu.org; Sun, 27 Mar 2016 16:27:50 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:37387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akHHo-0004Tu-HM for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 16:27:48 -0400 Received: by mail-wm0-f48.google.com with SMTP id p65so77783975wmp.0 for <13949@debbugs.gnu.org>; Sun, 27 Mar 2016 13:27:48 -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=Xrk7emaCUkZa1CS8o/xTefVznNJnFMu6uzWvMdPCq/w=; b=fV8VGNiYSDc+YsSVfJSDyI0GCKhju96e230WKECMtSR6ruKCOeNrCDoMCvNq6Fz3+U LTgLU5f4njiale/Kf8jED3zfRnmxy5Vs5E2Q3GE0863OoZEgMtN0x/5AqhK2nB9tIvwn wHcpt8wQKwTC2/1uPC4B2dgGB7kfADdyiCXYEg4C3wiM2xrWuIP+GL0inmhfQyu4b7+4 Vkpxo7D0R27ywKEBtkGMDkE8HGecxNLfdAbj4jBP4XMjY4sGh6Lr130eJSVsSkz57QaM vDIVNszDtxasyze8gVZahfPc3XXQPLMPJjMY6PGRUzNJFcqXSd9N4xpI16NNgYTnUEwj 73HQ== 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=Xrk7emaCUkZa1CS8o/xTefVznNJnFMu6uzWvMdPCq/w=; b=TRMp72YmNTbmi7vqcEPn/xhGtDIXJ2dliGtsYlVmrbXK6K8++bV2+4RKhn+jf/6oju qFIwVa7Dn6KaJKg2OLJaiGJk37Ud242emqXgrArGutkXLKLxC8oj2xMtukpqs6XW3hUt DyPiAym7pN0ioQTpI0CdDm2UL8Rzf3SAPMKUnUi7jD6ehIlEeaKX/BcJnGKPIS8Jh9mD jeViSOluXVvpHy2Ba5UbcZ8KI2V2M16iUqAMaSr1tsn3VP76m/sMMAHn1H7MRDeCeBZF iADQRteqnY0oCoWzl56SFTh0+OTx6ACyWqzvzGTLeo1ETLMjJjFpKyme8emst0NPW+v4 g+TQ== X-Gm-Message-State: AD7BkJJeead+3z+3SYBqEO/FzSj+OQyhgTrX4ZrS495aHsQTnv6N8JQCbgtLTz8UQOgTdg== X-Received: by 10.194.62.179 with SMTP id z19mr26426929wjr.96.1459110463046; Sun, 27 Mar 2016 13:27:43 -0700 (PDT) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id v5sm7128716wmg.16.2016.03.27.13.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 13:27:42 -0700 (PDT) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: Lars Magne Ingebrigtsen 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> <83927858-0341-096f-b7e2-1322489efda8@yandex.ru> From: Dmitry Gutov Message-ID: <18327194-f403-d5d6-7bc6-8a0c4ede4d2a@yandex.ru> Date: Sun, 27 Mar 2016 23:27:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 Cc: =?UTF-8?Q?=c3=93scar_Fuentes?= , John Wiegley , Jaakov , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 03/27/2016 06:50 PM, Lars Magne Ingebrigtsen wrote: > Comparison is fast, but making a copy of a buffer (or its contents) > isn't. (If the buffer is large, that is.) If you've loaded a 2GB file > and hit `M-q' on a line, it would be rather awkward if that made Emacs > allocate an additional 2GB of data. Compare the "current paragraph", then (its bounds can be saved at the beginning of the fill-paragraph). Or track the affected area via before-change-functions. buffer-undo-list should also have the necessary information. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 17:05:52 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 21:05:53 +0000 Received: from localhost ([127.0.0.1]:40450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akHse-0005QP-OF for submit@debbugs.gnu.org; Sun, 27 Mar 2016 17:05:52 -0400 Received: from relaycp02.dominioabsoluto.net ([217.116.26.74]:42485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akHsb-0005QA-TA for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 17:05:51 -0400 Received: from smtp.movistar.es (smtp08.acens.net [86.109.99.132]) by relaycp02.dominioabsoluto.net (Postfix) with ESMTP id 7DC44D22CC; Sun, 27 Mar 2016 23:05:43 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.56F84B27.00A8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BAF155034C6B43; Sun, 27 Mar 2016 21:05:43 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> Date: Sun, 27 Mar 2016 23:05:42 +0200 In-Reply-To: <6d4fb517-8fc7-6d8f-afce-9387e509a46c@yandex.ru> (Dmitry Gutov's message of "Sun, 27 Mar 2016 23:24:55 +0300") Message-ID: <87shzb8wd5.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Lars Magne Ingebrigtsen , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Dmitry Gutov writes: > On 03/27/2016 06:53 PM, Lars Magne Ingebrigtsen wrote: > >> I look forward to seeing you visiting the git mailing list and starting >> to agitate for not using sha-1 hashes as object identifiers in git, >> because it might obviously lose data if you happen to get collisions. > > a) Why didn't they use md5, I wonder? AFAIK, at first they intended to use the hash as a method for avoiding malicious tampering of the VC contents, and MD5 was already broken as a crypto hash algorithm. (It is entirely different to find a collision by chance and to *fabricate* a collision; MD5 is broken for the later, but reliable for preventing the former.) 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.) 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. > 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? 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... We can be confident that this would happen multiple times out there, the contrary of having the same MD5 for the pre- and post- result of fill-paragraph. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 17:20:18 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 21:20:18 +0000 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 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 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) 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) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: =?UTF-8?Q?=c3=93scar_Fuentes?= 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> From: Dmitry Gutov Message-ID: <343192e9-ea13-21fa-45be-b2d1737bedb7@yandex.ru> Date: Mon, 28 Mar 2016 00:20:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <87shzb8wd5.fsf@wanadoo.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Lars Magne Ingebrigtsen , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 17:36:55 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 21:36:55 +0000 Received: from localhost ([127.0.0.1]:40467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akIMg-0006E7-U9 for submit@debbugs.gnu.org; Sun, 27 Mar 2016 17:36:55 -0400 Received: from huan1.mail.rambler.ru ([81.19.66.27]:4523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akIMe-0006Dy-GK for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 17:36:53 -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:Subject; bh=q34rqYfTQZcrszroKbjnqGeY8s5RQ9DqkZabCfMW23g=; b=AtfFwgpu/FuxUcFFWvK5CdxHb7J3kJL0csCIsN4tbRL8Ewl2xssg0Qs38bFk7cnSqV+8Tehz72VYxbrWgyzqDnzYrjLfy2C/R+qJIl0YGlxFk4p7o/y/G/CwigcZxHniuI0nvjt/PnL9BTsNXGqykdOidG56W02j3NZAOtGRlN0=; Received: from [UNAVAILABLE] ([93.204.110.126]:53150 helo=[192.168.3.203]) by huan1.mail.rambler.ru with esmtpa (Exim 4.76) (envelope-from ) id 1akIMB-0006dV-M1 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 00:36:29 +0300 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83927858-0341-096f-b7e2-1322489efda8@yandex.ru> <18327194-f403-d5d6-7bc6-8a0c4ede4d2a@yandex.ru> From: Jaakov Message-ID: <56F85256.2070208@ro.ru> Date: Sun, 27 Mar 2016 23:36:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <18327194-f403-d5d6-7bc6-8a0c4ede4d2a@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Rambler-User: j_k_v@ro.ru/93.204.110.126 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: For every hash function X, there is a set m(X) of people who are likely to abhor hash-checked-implementation of buffer modification: m(X) = the maintainers of databases of collisions for X. For each X: today, m(X) may be empty, small, or large, but, as the time goes by and hash functions remain, m(X) will be growing. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.27 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [81.19.66.27 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: For every hash function X, there is a set m(X) of people who are likely to abhor hash-checked-implementation of buffer modification: m(X) = the maintainers of databases of collisions for X. For each X: today, m(X) may be empty, small, or large, but, as the time goes by and hash functions remain, m(X) will be growing. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [81.19.66.27 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [81.19.66.27 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid For every hash function X, there is a set m(X) of people who are likely to abhor hash-checked-implementation of buffer modification: m(X) = the maintainers of databases of collisions for X. For each X: today, m(X) may be empty, small, or large, but, as the time goes by and hash functions remain, m(X) will be growing. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 27 18:03:14 2016 Received: (at 13949) by debbugs.gnu.org; 27 Mar 2016 22:03:15 +0000 Received: from localhost ([127.0.0.1]:40485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akImA-0006rG-Lz for submit@debbugs.gnu.org; Sun, 27 Mar 2016 18:03:14 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:39516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akIm8-0006r0-KJ for 13949@debbugs.gnu.org; Sun, 27 Mar 2016 18:03:13 -0400 Received: from smtp.movistar.es (smtp11.acens.net [86.109.99.135]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id AAB724301; Mon, 28 Mar 2016 00:03:06 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0206.56F8589A.0114, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56BC428E034F8028; Sun, 27 Mar 2016 22:03:22 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Dmitry Gutov Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <343192e9-ea13-21fa-45be-b2d1737bedb7@yandex.ru> Date: Mon, 28 Mar 2016 00:03:05 +0200 In-Reply-To: <343192e9-ea13-21fa-45be-b2d1737bedb7@yandex.ru> (Dmitry Gutov's message of "Mon, 28 Mar 2016 00:20:08 +0300") Message-ID: <87lh538tpi.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: John Wiegley , Lars Magne Ingebrigtsen , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Dmitry Gutov writes: > On 03/28/2016 12:05 AM, =C3=93scar 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? As stated on my previous message, statistically it is entirely different to avoid collisions among pairs of objects than within arbitrarily large sets. For this case we are on the pair scenario. IIUC, Lars' idea about using hashes on buffers to test for modification also is the pair case. >> 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. For naturally occurring modifications (opposed to specially chosen modifications with the purpose of creating collisions), inserting newlines or any string makes little difference to the hash algorithm. >>> 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. This would not work, for several reasons (colliding commits exists before they are merged or incorporated into a repo where they met; file and tree objects, whose content is identified by their SHA-1 hashes, can not be "retried"; etc.) Having a collision is something that Should Not Happen on Git, and the designers chose a crypto hash precisely because those algorithms are the best at avoiding collisions. >> 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. What about a file with lots of lines? If you intentionally press M-q on such a file and see the modified indicator, you either will assume that the file changed or use `diff-buffer-with-file' to check for modifications and possibly be greeted with a very long (possibly longer than the original file) diff that will render Emacs to its feet. Using the hash approach will put the "too long" threshold on a higher level (or eliminate it altogether), does not require extra memory and it is simpler to implement. Dmitry, if your proposal about comparing the paragraphs is motivated only by your fear of hash collisions, you are way out off the mark there :-) From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 04:00:14 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 08:00:14 +0000 Received: from localhost ([127.0.0.1]:40746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akS5u-0004FB-IZ for submit@debbugs.gnu.org; Mon, 28 Mar 2016 04:00:14 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:50991) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akS5t-0004Ex-2i for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 04:00:13 -0400 Received: from [192.168.178.35] ([95.119.46.51]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MHGU7-1aY42L1pxb-00E489; Mon, 28 Mar 2016 10:00:02 +0200 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: =?UTF-8?Q?=c3=93scar_Fuentes?= 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> <56F78F77.8000008@easy-emacs.de> <87y494arfr.fsf@wanadoo.es> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <56F8E4F2.1060400@easy-emacs.de> Date: Mon, 28 Mar 2016 10:01:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <87y494arfr.fsf@wanadoo.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:llLvGKkx6gNskxOxftJFAXEYILjuomzqK4uR4oOtBcDRz8yC4+1 /vwdxFh42ZNOe7hngJ2g8uhbrGohYAmtEZWcocPkcy+MJ6B/zpnqyx2bdK1qf8nutcAiH1j xTKDlvCDFoWnV7OrEc3fU0YQN+hDsvttkSmnXco8GKYA8lUqbdHuUZrM/XV7bMnHqUUwWA+ si3hRPnF1S18Xw0T8CESQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:6+wSUh1b4nM=:5v9w/aFOVPFoElYftfyfWd D3pa2iUoiuwwGCccGFiS8Y1p4BPz2eAvPH9tsQWS62Q8TfyTlD04s2bniUX1bgr4T25zAd073 m0Z3QK0njLm9Lq65L6jG6qydkv9hzMUoqwWMINO2Brtffz64R7m4yzFlcc6Zebf1CjNct6fms iauJ6Eu88a26KAn5VC2hVljCLevEJ8jeAMfQ73/9f/GnEE7r/nF5Iu7IXz+gL5aJO+jjzFKhU 00moUlTQjFqy7XU+iez99YXSJlKDppSDUI/hLt/Jcw3VFxndtjWru8+XzcE6OXb8y7/E+/XRB dT6vTtCIa2wAUw/THmDcbEQr308wLm5YwiZ5EAgpYzCC70n3t1gasWP5Uk4iY/HoGNqPk/HRj yWXDCS38+Lebql+pJ5C5pC+xK6bMsLCT70ouvCsCwmY3ru8gzfQuqrknyuisl7af0eVu4xz7q x4x+MTF5od/xng3uweBxsUcmVk/aZ19YVxa3ntag8UgvaY82lAGLrJDy3a/O4J6bVB56+bzYL utTRa/l8C+MDisNKhZe0DI5rlrllhiOMIMHzVdRwQmlPAdHoBmdur/fXbgNH9QAKgDdJCZHK0 Qg9ulBRcUtT5WDvrLeOeWKncOZ2R0s7qRLpB+7ZkcK17B+WIJD4hG3Nkiw7tLsbcm4oMcfKpI xTVXxUTk/lSDdRgn3QUlGvtPCBch2MO59CvPrFTdkhip+siNvCXGYKMxAWnmVZF1hD9mqrjwf 2b9OrAmqwLEs3c2E X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 27.03.2016 17:09, Óscar Fuentes wrote: > Andreas Röhler writes: > >> Another solution would hash only the paragraph in question, re-format >> it in a temp buffer and replace original content only if changed. > If we know the paragraph's begin and end points, we can hash just that > range and then there is no need of a temporary buffer. I think that this > condition is met on all cases. Ideally fill-paragraph would know about the borders of action. > Anyway, I've made some experiments and hashing a 160 MB file on a 8 year > old 2.4 GHz 64 bit workstation takes 2.4 seconds. If there is a faster solution, why not use them? Sure such a function isn't called somewhere repeatedly, travelling paragraph by paragraph? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 04:08:26 2016 Received: (at submit) by debbugs.gnu.org; 28 Mar 2016 08:08:26 +0000 Received: from localhost ([127.0.0.1]:40750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akSDm-0004QG-Bs for submit@debbugs.gnu.org; Mon, 28 Mar 2016 04:08:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akSDk-0004Q4-O1 for submit@debbugs.gnu.org; Mon, 28 Mar 2016 04:08:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akSDe-0003Io-IR for submit@debbugs.gnu.org; Mon, 28 Mar 2016 04:08:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akSDe-0003Ik-FU for submit@debbugs.gnu.org; Mon, 28 Mar 2016 04:08:14 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akSDd-0007yP-Ak for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 04:08:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akSDc-0003IJ-9D for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 04:08:13 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:55106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akSDX-0003HV-L0; Mon, 28 Mar 2016 04:08:07 -0400 Received: from [192.168.178.35] ([95.119.46.51]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0Mg7K1-1aPm8e369d-00NTCv; Mon, 28 Mar 2016 10:08:05 +0200 Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified To: bug-gnu-emacs@gnu.org 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> From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: <56F8E6D6.9060108@easy-emacs.de> Date: Mon, 28 Mar 2016 10:09:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <83lh54ynol.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:eIz7dB/m5GRvD4n7+Q0zSfE2Et7rd4Kfel1h4MLZHAXes5IiePW oc/xCt/fdsqLx2EHP9o/rkzo0Gx6DnJv6Y1z5ZIY5NvqNznSVhsPOY4HXRebvRIKhuOq9if DcHts0/BNS7CKegXJZwT2uMb1F2xMRPtpqvvtzpOy35Er5YaIUkPqAj7659tU48NK8L2p0c ArfpXSkQNXUKwehBQiL+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:IYEWVqOUWgo=:Ia/8jhbZfcCwEJK9pR2ihB VqWqoKMxRvx3hPDhQ+LRzng5FWXeFcm/N08QX+q9mGp3vKuzV+W2vC+wQ++zzgdCS1SegCNTQ eVtSd3esPi7kQdHLazwqUZ2ekaxrmJNa7oKJ1zzJHlDvfHSMi45tkqKtyqwrPWVZNR2PAmW2n z/PYCc3SoqeF+t5He6wzYz4eBQuDeMBpIJ9SIW/k6COBMVeyPPaXV1hz6NQsSnbo4bwTB3N1s 22j1yqd8Ev/7KgDYB48guWQmfsPYMZusgHQbsDtQzMD710yjzECpjQhH8FPQySi0ey/cvZ0pE Xj5WIbbARcdkDyq4nsOJ4g9cUotihMaYfY8TA1Vt1MAGwTraWEnQvrBmaUK97Nf2y/UTTR/EH FlTlEGGjHMmFlgnPjxBK7GT/6NWfyvSgE110KXAD7MrvqtoA7hN9pp4Hz8COBOsjR+yq+Zvgp MufhdSvSVZRzlzSSplVCpAQBZZLFBBmR6N40jDIxLLtlHXR7QssJqTy20GThZWDJnqaiJE4q5 aimSZuMmiHmL0jExElyGUS28fmnf3b5G7JGqKw3Dlg0lSdSqPqKERDW7t2GRhKQO4A6jkSTtG C63n9Aum3SkN+DbeQVSPkf1eDiJ7tUfq/GQ83Hs7OfNnuKgV4y4zls2YL9xVGaQ03EqMoNn4T yGe/1XSvWzHwc/KAmGiBtZODDBf75u2Z3a/34UyQ3kV+L/6q1ish3Uf1cEOZHNQrkRXxtB7Ga 0P2DsPC6fiqtQmTV X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 27.03.2016 16:56, Eli Zaretskii wrote: >> From: Óscar Fuentes >> Date: Sun, 27 Mar 2016 05:31:19 +0200 >> Cc: Jaakov , 13949@debbugs.gnu.org >> >> diff --git a/lisp/textmodes/fill.el b/lisp/textmodes/fill.el >> index 100e2a2..9e1f430 100644 >> --- a/lisp/textmodes/fill.el >> +++ b/lisp/textmodes/fill.el >> @@ -804,6 +804,7 @@ fill-paragraph >> (interactive (progn >> (barf-if-buffer-read-only) >> (list (if current-prefix-arg 'full) t))) >> + (setq h (if (buffer-modified-p) "" (secure-hash 'md5 (current-buffer)))) >> (or >> ;; 1. Fill the region if it is active when called interactively. >> (and region transient-mark-mode mark-active >> @@ -862,7 +863,10 @@ fill-paragraph >> ;; fill-region. >> (fill-region beg end justify) >> (fill-region-as-paragraph beg end justify)))))) >> - fill-pfx))) >> + fill-pfx)) >> + (when (and (not (string= h "")) >> + (string= h (secure-hash 'md5 (current-buffer)))) >> + (set-buffer-modified-p nil))) > Thanks, but I'm not sure computing the hash is enough: the functions > involved in refilling can change text properties, so the test should > also account for that. > > > Maybe restrict the notion of changes here to all values, which an auto-save would store? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 04:50:34 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 08:50:34 +0000 Received: from localhost ([127.0.0.1]:40757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akSsc-0005Nd-8e for submit@debbugs.gnu.org; Mon, 28 Mar 2016 04:50:34 -0400 Received: from mout.gmx.net ([212.227.15.15]:64845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akPDh-0008JE-MO for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 00:56:06 -0400 Received: from [193.147.107.1] by 3capp-gmx-bs61.server.lan (via HTTP); Mon, 28 Mar 2016 06:55:58 +0200 MIME-Version: 1.0 Message-ID: From: "Petros Travioli" To: 13949@debbugs.gnu.org Subject: fill-paragraph is buggy, but using MD5 is even more buggy Content-Type: text/plain; charset=UTF-8 Date: Mon, 28 Mar 2016 06:55:58 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:37xiuKV9vqlgQZAsQB8MUlR4naMq6G/jpcHxEK0OrcC K/BsNwoh9Fn799hs/o4HrwSxm5DtGFmhrjIIoBCjq0VII7TkkL D/Lc+2WcUsCNoCkwYCFA1vAH3ar4175bgpMI5/MyfN2SaNFhqU WZQt+C/dkOPoQYVpUCsGRlKV2vbpdPw76PBNOHLwPqpzx/RrN+ zKPx09WM1qEFkxq4Qx2Etzjk0ImQP/K6qFY0qeM/8naD1YifRd tJz6i/5qLR88CSgieiE9JXiiyb0d+fMP6aMz8Xo0RfjFwPf3PK mJwC3I= X-UI-Out-Filterresults: notjunk:1;V01:K0:EZiZ5+0Gj3A=:9sXITP3wyFsWS4gZQxcy11 kUz9Ypni3bm88rz/OeTvnVhQ8Q1QUaQJ+H03q3kLOouWPwHqmVhTpTNorDQ218npADepkRnYI CDplBR6aJwFOGEYzqm2TrJ8HjlLtvat+KQcY9tig8umd0DQHU/mkGRVYncneuEh10RBmV5Nfh FXwszUoJYZaD5uPQ0sj6G/h79/KNLve8N71tNkqBMpI4+WGplQJE2MnG/Qe9KJEhN3HGpPOwZ uHQWI5HUCMjQnNYBifPCVZZs9ps/5N2WLDECRVo8Ae0sG4O36m/rdso0db6y27cIGNbav8xHb K+bsiXVCn84zwM5pZ8nodWNbguFvEtvAHTlPkd7K+bCteQmpN7cx+32xy5/UfB9/uYCexsdwI /DGugj2nFewBh+/ECoUGvdQUqRSBey/shDQ0G3suIGRDib9FpSnUMxo0UECY6wb/UwpDGLusf qLVvyuLFVg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 X-Mailman-Approved-At: Mon, 28 Mar 2016 04:50:31 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Some details on hashes. For eggheads. Let's assume that you have never typed in some large number, say, 89434823472. And you have never seen it so far. And noone you know has ever seen this number. Neither have your colleagues, though you don't speak to them. On this empirical basis, you declare this number nonexistant for all practical purposes. Encountering this number in the future is less likely than the probability of finding oneself with those two sweet blond ladies you've always wanted at your home in a horizontal position simultaneously. Since instead of the ladies, you have been accustomed to endure the society of your wife, well, you decide to use the value 89434823472 as an error value when, say, returning the file size. Is it clever? Of course NO. There is absolutely nothing which precludes the next large file you see to have size exactly 89434823472. There is absolutely nothing which precludes the next two large files you see to have this size. As the time goes by, files get larger, so 89 GB files may be normal in a decade or so. (The ladies will never change their mind, though. Sigh.) But that's exactly what happens when you are using hash functions to verify buffer equality, just with a more complicated mathematical formulation and at a slightly different scale. So don't use hash functions to a two-sided correct answer to test buffer equality. For a one-sided answer (if hash(x) != hash(y) then x != y), you are fine. Petros From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 06:32:31 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 10:32:31 +0000 Received: from localhost ([127.0.0.1]:40814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akUTH-00083f-8y for submit@debbugs.gnu.org; Mon, 28 Mar 2016 06:32:31 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:39249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akUTE-00083W-MA for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 06:32:29 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3qYVbH5BYwz3hjYx; Mon, 28 Mar 2016 12:32:27 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3qYVbH2zqzzvdWQ; Mon, 28 Mar 2016 12:32:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id 0pwLGoPhd1L9; Mon, 28 Mar 2016 12:32:26 +0200 (CEST) X-Auth-Info: n1DkNj5xS2R/zYhqS0gAV2c4Q1YFm9cy6IBS0U+KxnoV2K+SyIhT+XTHzhSyLXv4 Received: from igel.home (ppp-88-217-16-153.dynamic.mnet-online.de [88.217.16.153]) by mail.mnet-online.de (Postfix) with ESMTPA; Mon, 28 Mar 2016 12:32:26 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 4135F2C3E2B; Mon, 28 Mar 2016 12:32:26 +0200 (CEST) From: Andreas Schwab To: "Petros Travioli" Subject: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy References: X-Yow: Look into my eyes and try to forget that you have a Macy's charge card! Date: Mon, 28 Mar 2016 12:32:26 +0200 In-Reply-To: (Petros Travioli's message of "Mon, 28 Mar 2016 06:55:58 +0200") Message-ID: <87r3euhozp.fsf@linux-m68k.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) "Petros Travioli" writes: > But that's exactly what happens when you are using hash functions to > verify buffer equality, just with a more complicated mathematical > formulation and at a slightly different scale. > > So don't use hash functions to a two-sided correct answer to test buffer > equality. For a one-sided answer (if hash(x) != hash(y) then x != y), you > are fine. There is a difference between a hash function and a cryptographic hash function. An inportant property of a cryptographic hash function is the avalanche effect, that means a small change in the plaintext will result in a big change in the hash value. That makes such a hash function suitable for the reverse condition x != y => hash(x) != hash(y), with a very high probability of being true. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 06:40:09 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 10:40:09 +0000 Received: from localhost ([127.0.0.1]:40819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akUac-0008EF-2H for submit@debbugs.gnu.org; Mon, 28 Mar 2016 06:40:09 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:44168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akUaX-0008Dj-0z for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 06:40:04 -0400 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 1akUaR-0000NR-Dx; Mon, 28 Mar 2016 12:39:59 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAKlBMVEX53Tr77GP+/v4HAgX+ 5C0FAAGcd2fszERQGjY7LkxvS2gfCBYEAAHKnFbmmUyyAAACR0lEQVQ4jW2TPWvbQBjHRQnJ5KUf 4YZAkvEQSXEGDyaaNIkbChpKCldqY/BkQcFLC+ZSbzUdzu5UQ5CuZBIFK5dMQUvREIo508B9l96L ZMtx/tL0/Ljn5X/3OO2NLqCLEHJRAJWcF4AhFnhSyvZQwClLbhn7jtygBL4CnhRNRvX3O0AVGPTE Y0PiN2yaBEznq4CQ4h2WWKWZvE0QyivQUkGBMZ5O2PmfeR4WeQk8jHti6WOKpne3Pwqlh612/bCo lD8DYQ1EWo7j9A9Eh1K4liNLiZjcSKBYqSqVF6P4MwDgY5ijreJPhMQjBcC8yOvAjwkhTINjNfh6 DnWAMWYBmCAUri3xxpzzhYmDI+1V1ZUwjTArSrnuak+fGHbvG3x8f2NzQaTnMLkex6cXMD0lBsyt 7QbglcCEjFavNTgxt25Seau+NmawfGWqQ3PnBvRsC/bEkfVKp/KvrD8/QQ2sVI4hpbOM02ts1OFa JpX/hc2bMPkG6idMDcp+ZfQF0NYDJ9NrC05qoGPNsOD9pqv2P9OUjStLNlf7ZE20bZVX23ecVssn C8LHi5GtnTZT1a69kO5ZDNMzY+K8fCXlahCjvwAcplug1dHxr5cAdKt3tVd7DaNLcJxWIColiDbx cMZ5U0kVl2t1rmhCd16i1n4K7cbubC3Sgsh1nwM3UEH1l6DVkx8GQgx8a8ZM/RZ4crXUxRtiltnC k6KWKor6+xA2zwu7ghugjgwympnVLOrFo4PoE+T8TseDnXZDvTV5+LDTrt6yAoV6wP/G09K5SCpj jAAAAABJRU5ErkJggg== Date: Mon, 28 Mar 2016 12:39:54 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 27 Mar 2016 18:28:43 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Magne Ingebrigtsen writes: > for iterate_over_all_intervals > sha1_process_bytes(interval, len) I completely forgot about the distinction between text property changes that "count" and the ones that don't here. Font locking, for instance, runs with `with-silent-modifications' so those changes "don't count", but there's nothing in the intervals themselves that you can examine after the fact, as far as I can tell. Is that correct? So the question is, I guess: Does `M-q' does something to text properties that we have to keep track of, or is it sufficient to just hash the buffer contents to determine whether `M-q' did something? (Please take any further discussions about how likely it is that an editing change will end up with the same sha1 to the emacs-tangents mailing list.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 07:27:55 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 11:27:55 +0000 Received: from localhost ([127.0.0.1]:40845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVKs-0000sO-Oz for submit@debbugs.gnu.org; Mon, 28 Mar 2016 07:27:54 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:44999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVKr-0000sG-KS for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 07:27:54 -0400 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 1akVKo-0000jF-A7 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:27:52 +0200 From: Lars Magne Ingebrigtsen To: 13949@debbugs.gnu.org Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEXx0LE2ISr968Lfu578 3rj317WXdGdrrzSBAAACXUlEQVQ4jV3UzZKjIBAAYBJjzul1i3OqJZ51SDy7DOyZysicg9bw/o+w 3RAzU0tVSsNHN/+KYKlclTGIqHYy3fA887vgentQ9KoJQI7Gmg0Mcj02qI4g04K5iJmFM7UNXkYp 0xfucUtlrEXsCERKaUUz0f8Cqs2g7gSJWt/3W6p2z6kQx5SkuU/BGQJKpHDBvgBIPDjvSwSl7Nvf mmAg2BvvBfeByih8HyQNRhHAFScxcYTiiAHgxCAjPIwSuXMkOAMA9XEeJAANy9dbH+0TdpDhtVa2 K6A+6SnNN7j4hA96rvvXWtkjPKGjFl/WvCDS4jFgFxOs4b5BiLCOBAo7SFG7+QWfMnGEMgSpd5xL 8NYGLzTD5dDSTtX2CTOB1wOBEx1IbpqB6kPwVYF3GtQGbmYQEU7KCZrHiZreuXNHfQSXgXKOUfpr hhDsFnG14e6PoG88XlEHLt7TzJs53KcK1lv4ARWtajM7M4nY1BnCnOEIzdAc3H4Sxw1KxA4eab05 82cVzc0ftlSeQTa92P+FURYQW8QaG52WkTbqJg7fqQbQkVZy0QVMSVV7H6GHdR1/dTIxWFNS0TSk lmv/sXR0eBksQ10LQQC69kv7E4IQR0gM7qEIdAHhawZNe1rpFTPMDLWniB1oPSTdJ74Ij2ouEQxS 63GdXYa+shm4DA1BM1cJuxR7UcDTb1y1fqODIAmkuH1D0gR81LGNTT5Sz1QjA81B4jk+8nku9VWO wIo+GJjE9T+gT4Ki+97zYK17Ag/qLd85vPQcEJ5dZCgRFz60jqHXVaTRjkuJUI4PVP0PlNneFLie r24AAAAASUVORK5CYII= Mail-Copies-To: never Date: Mon, 28 Mar 2016 13:27:49 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 28 Mar 2016 12:39:54 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) I've now made a simple buffer hashing function (that does not take text properties into account) to see how slow this would be. The following form (with-temp-buffer (dotimes (i 10000) (insert (make-string 100 ?k) "\n")) (benchmark-run 1000 (buffer-hash))) takes 2.7 seconds (that's 1000 1MB buffers), and unsurprisingly (with-temp-buffer (dotimes (i 10000000) (insert (make-string 100 ?k) "\n")) (benchmark-run 1 (progn (message "%s" (buffer-size) (buffer-hash))))) (which is 1 1GB buffer) takes the same amount of time. :-) (This is on a 2.7GHz i5 from like five years ago.) So on big buffers this isn't really something you'd want to run a lot, but it's workable (especially since in the `M-q' case you'd only run it if the buffer isn't already modified). So... diff --git a/src/fns.c b/src/fns.c index 0e3fc27..d027058 100644 --- a/src/fns.c +++ b/src/fns.c @@ -4737,6 +4737,22 @@ It should be the case that if (eq (funcall HASH x1) (funcall HASH x2)) #include "sha256.h" #include "sha512.h" +static Lisp_Object +make_digest_string (Lisp_Object digest, int digest_size) +{ + unsigned char *p = SDATA (digest); + int i; + + for (i = digest_size - 1; i >= 0; i--) + { + static char const hexdigit[16] = "0123456789abcdef"; + int p_i = p[i]; + p[2 * i] = hexdigit[p_i >> 4]; + p[2 * i + 1] = hexdigit[p_i & 0xf]; + } + return digest; +} + /* ALGORITHM is a symbol: md5, sha1, sha224 and so on. */ static Lisp_Object @@ -4936,17 +4952,7 @@ It should be the case that if (eq (funcall HASH x1) (funcall HASH x2)) SSDATA (digest)); if (NILP (binary)) - { - unsigned char *p = SDATA (digest); - for (i = digest_size - 1; i >= 0; i--) - { - static char const hexdigit[16] = "0123456789abcdef"; - int p_i = p[i]; - p[2 * i] = hexdigit[p_i >> 4]; - p[2 * i + 1] = hexdigit[p_i & 0xf]; - } - return digest; - } + return make_digest_string (digest, digest_size); else return make_unibyte_string (SSDATA (digest), digest_size); } @@ -4997,6 +5003,44 @@ It should be the case that if (eq (funcall HASH x1) (funcall HASH x2)) { return secure_hash (algorithm, object, start, end, Qnil, Qnil, binary); } + +DEFUN ("buffer-hash", Fbuffer_hash, Sbuffer_hash, 0, 1, 0, + doc: /* Return a hash of the contents of BUFFER-OR-NAME. +If nil, use the current buffer." */ ) + (Lisp_Object buffer_or_name) +{ + Lisp_Object buffer; + struct buffer *b; + struct sha1_ctx ctx; + Lisp_Object digest = make_uninit_string (SHA1_DIGEST_SIZE * 2); + + if (NILP (buffer_or_name)) + buffer = Fcurrent_buffer (); + else + buffer = Fget_buffer (buffer_or_name); + if (NILP (buffer)) + nsberror (buffer_or_name); + + b = XBUFFER (buffer); + sha1_init_ctx (&ctx); + + /* Process the first part of the buffer. */ + sha1_process_bytes (BUF_BEG_ADDR (b), + BUF_GPT_BYTE (b) - BUF_BEG_BYTE (b), + &ctx); + + /* If the gap is before the end of the buffer, process the last half + of the buffer. */ + if (BUF_GPT_BYTE (b) < BUF_Z_BYTE (b)) + sha1_process_bytes (BUF_GAP_END_ADDR (b), + BUF_Z_BYTE (b) - (BUF_GPT_BYTE (b) + BUF_GAP_SIZE (b)), + &ctx); + + sha1_finish_ctx (&ctx, SSDATA (digest)); + return make_digest_string (digest, SHA1_DIGEST_SIZE); +} + + void syms_of_fns (void) @@ -5156,6 +5200,7 @@ It should be the case that if (eq (funcall HASH x1) (funcall HASH x2)) defsubr (&Sbase64_decode_string); defsubr (&Smd5); defsubr (&Ssecure_hash); + defsubr (&Sbuffer_hash); defsubr (&Slocale_info); hashtest_eq.name = Qeq; -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 07:32:27 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 11:32:27 +0000 Received: from localhost ([127.0.0.1]:40850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVPD-0002cD-B3 for submit@debbugs.gnu.org; Mon, 28 Mar 2016 07:32:26 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:45073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVP8-0002bi-L1 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 07:32:22 -0400 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 1akVP4-0000lI-4m for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:32:18 +0200 From: Lars Magne Ingebrigtsen To: 13949@debbugs.gnu.org Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEXx0LE2ISr968Lfu578 3rj317WXdGdrrzSBAAACXUlEQVQ4jV3UzZKjIBAAYBJjzul1i3OqJZ51SDy7DOyZysicg9bw/o+w 3RAzU0tVSsNHN/+KYKlclTGIqHYy3fA887vgentQ9KoJQI7Gmg0Mcj02qI4g04K5iJmFM7UNXkYp 0xfucUtlrEXsCERKaUUz0f8Cqs2g7gSJWt/3W6p2z6kQx5SkuU/BGQJKpHDBvgBIPDjvSwSl7Nvf mmAg2BvvBfeByih8HyQNRhHAFScxcYTiiAHgxCAjPIwSuXMkOAMA9XEeJAANy9dbH+0TdpDhtVa2 K6A+6SnNN7j4hA96rvvXWtkjPKGjFl/WvCDS4jFgFxOs4b5BiLCOBAo7SFG7+QWfMnGEMgSpd5xL 8NYGLzTD5dDSTtX2CTOB1wOBEx1IbpqB6kPwVYF3GtQGbmYQEU7KCZrHiZreuXNHfQSXgXKOUfpr hhDsFnG14e6PoG88XlEHLt7TzJs53KcK1lv4ARWtajM7M4nY1BnCnOEIzdAc3H4Sxw1KxA4eab05 82cVzc0ftlSeQTa92P+FURYQW8QaG52WkTbqJg7fqQbQkVZy0QVMSVV7H6GHdR1/dTIxWFNS0TSk lmv/sXR0eBksQ10LQQC69kv7E4IQR0gM7qEIdAHhawZNe1rpFTPMDLWniB1oPSTdJ74Ij2ouEQxS 63GdXYa+shm4DA1BM1cJuxR7UcDTb1y1fqODIAmkuH1D0gR81LGNTT5Sz1QjA81B4jk+8nku9VWO wIo+GJjE9T+gT4Ki+97zYK17Ag/qLd85vPQcEJ5dZCgRFz60jqHXVaTRjkuJUI4PVP0PlNneFLie r24AAAAASUVORK5CYII= Date: Mon, 28 Mar 2016 13:32:13 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 28 Mar 2016 13:27:49 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Magne Ingebrigtsen writes: > + /* If the gap is before the end of the buffer, process the last half > + of the buffer. */ > + if (BUF_GPT_BYTE (b) < BUF_Z_BYTE (b)) > + sha1_process_bytes (BUF_GAP_END_ADDR (b), > + BUF_Z_BYTE (b) - (BUF_GPT_BYTE (b) + BUF_GAP_SIZE (b)), > + &ctx); Errr... this is all wrong. That's not how the gap thing works... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 07:39:11 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 11:39:11 +0000 Received: from localhost ([127.0.0.1]:40865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVVm-0002ld-F8 for submit@debbugs.gnu.org; Mon, 28 Mar 2016 07:39:11 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:45226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVVh-0002lP-JS for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 07:39:09 -0400 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 1akVVc-0000o9-VM for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:39:04 +0200 From: Lars Magne Ingebrigtsen To: 13949@debbugs.gnu.org Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEXx0LE2ISr968Lfu578 3rj317WXdGdrrzSBAAACXUlEQVQ4jV3UzZKjIBAAYBJjzul1i3OqJZ51SDy7DOyZysicg9bw/o+w 3RAzU0tVSsNHN/+KYKlclTGIqHYy3fA887vgentQ9KoJQI7Gmg0Mcj02qI4g04K5iJmFM7UNXkYp 0xfucUtlrEXsCERKaUUz0f8Cqs2g7gSJWt/3W6p2z6kQx5SkuU/BGQJKpHDBvgBIPDjvSwSl7Nvf mmAg2BvvBfeByih8HyQNRhHAFScxcYTiiAHgxCAjPIwSuXMkOAMA9XEeJAANy9dbH+0TdpDhtVa2 K6A+6SnNN7j4hA96rvvXWtkjPKGjFl/WvCDS4jFgFxOs4b5BiLCOBAo7SFG7+QWfMnGEMgSpd5xL 8NYGLzTD5dDSTtX2CTOB1wOBEx1IbpqB6kPwVYF3GtQGbmYQEU7KCZrHiZreuXNHfQSXgXKOUfpr hhDsFnG14e6PoG88XlEHLt7TzJs53KcK1lv4ARWtajM7M4nY1BnCnOEIzdAc3H4Sxw1KxA4eab05 82cVzc0ftlSeQTa92P+FURYQW8QaG52WkTbqJg7fqQbQkVZy0QVMSVV7H6GHdR1/dTIxWFNS0TSk lmv/sXR0eBksQ10LQQC69kv7E4IQR0gM7qEIdAHhawZNe1rpFTPMDLWniB1oPSTdJ74Ij2ouEQxS 63GdXYa+shm4DA1BM1cJuxR7UcDTb1y1fqODIAmkuH1D0gR81LGNTT5Sz1QjA81B4jk+8nku9VWO wIo+GJjE9T+gT4Ki+97zYK17Ag/qLd85vPQcEJ5dZCgRFz60jqHXVaTRjkuJUI4PVP0PlNneFLie r24AAAAASUVORK5CYII= Date: Mon, 28 Mar 2016 13:39:00 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 28 Mar 2016 13:32:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Magne Ingebrigtsen writes: > Errr... this is all wrong. That's not how the gap thing works... This seems to do the trick: /* If the gap is before the end of the buffer, process the last half of the buffer. */ if (BUF_GPT_BYTE (b) < BUF_Z_BYTE (b)) sha1_process_bytes (BUF_GAP_END_ADDR (b), BUF_Z_ADDR (b) - BUF_GAP_END_ADDR (b), &ctx); -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 09:46:44 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 13:46:44 +0000 Received: from localhost ([127.0.0.1]:40987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akXVB-0000aU-5Z for submit@debbugs.gnu.org; Mon, 28 Mar 2016 09:46:44 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:47849) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akXV5-0000aC-Qq for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 09:46:39 -0400 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 1akXUm-0001lD-By for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 15:46:34 +0200 From: Lars Magne Ingebrigtsen To: 13949@debbugs.gnu.org Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEXr6+P+/fz//9vOzrHL y6fGxq/AwKnT07X49vDX18L+/tf///+XjmT8/PjR0b21tpSBWwHZAAABnUlEQVQ4jZXSMUvDQBgG 4NNJyeSgUI72D7iK4KJLF6cu6eBSEIriUgdFiEPBLRBxMW0JSKOuIjZOaY90cystuNXDTYQsKmiL Q0nNJbkkzV0GvyG5y3Pv3eU4gGi9PAwm08kpQo/KkgI7ACGIkEEk5+jfBcUbhJEJaMBCub6+vSUE XSMEN9FXK2uCH0AoBt3+28ExTSCwGkLmSS0eEYBkYnAXTTVSS7FEDMbqZgJevWZ7rK6nQT0vGGRT 2INsMMaF93yw+MwambFY/Yl+MIL2SJTyiV1hDxxxo8zb7rJzKO0zkCVQrrIJg4CoFRLgbXDF+ZSS EKyhSyczgP1m19HtGi/RdWo293SHTtNu8iBT0WyNCyVt55KCGYIJhkXNbrCH2JpeFLWPBm+qq0lv MFUYaNV7bn1ZIdxQIN97gn9bCdzTIXvD3/NdFJ5DdOHOTGzicEH3isY68QKQ/93fFYNw5rYnEt5z KQ2iMtMgNUHL+l/CYBMWJIdlsYkspL+bAOy/TAIG4ha7OIzA4sK8jN125xY9K7IsXy+CBfclg7k/ 9CMPuQy3hJwAAAAASUVORK5CYII= Date: Mon, 28 Mar 2016 15:46:16 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 28 Mar 2016 13:27:49 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Lars Magne Ingebrigtsen writes: > takes 2.7 seconds (that's 1000 1MB buffers), and unsurprisingly With md5 it's 1.7 seconds, so that might be a better choice, although we'd have to deal with an endless string of bug reports about md5 being "broken" that we'd have to mark as "notabug wontfix closed" every three days, I think. :-) So it might not be worth it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 10:31:35 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 14:31:35 +0000 Received: from localhost ([127.0.0.1]:42148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akYCd-0001tz-Db for submit@debbugs.gnu.org; Mon, 28 Mar 2016 10:31:35 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:34596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akYCc-0001tr-DJ for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 10:31:34 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3qYbv96YxZz3hjQq; Mon, 28 Mar 2016 16:31:33 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3qYbv9666jzvPt1; Mon, 28 Mar 2016 16:31:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id 7Ecf-6PqAnFo; Mon, 28 Mar 2016 16:31:32 +0200 (CEST) X-Auth-Info: DEnvpO0oHq0gIKJV8XhD1If5OQFt+pQXuteoEaEc8/G0J7DF2AVlBcHJNWY7XSdX Received: from igel.home (ppp-88-217-16-153.dynamic.mnet-online.de [88.217.16.153]) by mail.mnet-online.de (Postfix) with ESMTPA; Mon, 28 Mar 2016 16:31:32 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 7F93E2C38EB; Mon, 28 Mar 2016 16:31:32 +0200 (CEST) From: Andreas Schwab To: "Petros Travioli" Subject: Re: Aw: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy References: <87r3euhozp.fsf@linux-m68k.org> X-Yow: But was he mature enough last night at the lesbian masquerade? Date: Mon, 28 Mar 2016 16:31:32 +0200 In-Reply-To: (Petros Travioli's message of "Mon, 28 Mar 2016 15:29:19 +0200") Message-ID: <87d1qehdx7.fsf@linux-m68k.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) "Petros Travioli" writes: >> > But that's exactly what happens when you are using hash functions to >> > verify buffer equality, just with a more complicated mathematical >> > formulation and at a slightly different scale. >> > >> > So don't use hash functions to a two-sided correct answer to test buffer >> > equality. For a one-sided answer (if hash(x) != hash(y) then x != y), you >> > are fine. >> >> There is a difference between a hash function and a cryptographic hash >> function. An inportant property of a cryptographic hash function is the >> avalanche effect, that means a small change in the plaintext will result >> in a big change in the hash value. That makes such a hash function >> suitable for the reverse condition x != y => hash(x) != hash(y), with a >> very high probability of being true. >> > So far most old crypto functions have been broken. There is no doubt this will happen to any newer one sooner or later. If any single person would lose his work because of a random collision, this is an argument agains crypto hash functions. This is irrelevant. See avalanche effect. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 11:16:11 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 15:16:11 +0000 Received: from localhost ([127.0.0.1]:42169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akYtj-0002ve-DO for submit@debbugs.gnu.org; Mon, 28 Mar 2016 11:16:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52187) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akYte-0002ut-Eo for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:16:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akYtV-0004II-0X for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:15:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akYtU-0004IB-NK; Mon, 28 Mar 2016 11:15:52 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4698 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akYtT-0001f4-IO; Mon, 28 Mar 2016 11:15:52 -0400 Date: Mon, 28 Mar 2016 18:15:32 +0300 Message-Id: <83twjqy6p7.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Mon, 28 Mar 2016 12:39:54 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Cc: 13949@debbugs.gnu.org > Date: Mon, 28 Mar 2016 12:39:54 +0200 > > Lars Magne Ingebrigtsen writes: > > > for iterate_over_all_intervals > > sha1_process_bytes(interval, len) > > I completely forgot about the distinction between text property changes > that "count" and the ones that don't here. Font locking, for instance, > runs with `with-silent-modifications' so those changes "don't count", > but there's nothing in the intervals themselves that you can examine > after the fact, as far as I can tell. Is that correct? The intervals do store the property itself, but I actually don't understand why should you bother discerning between faces and the other properties. If the buffer text is really unchanged, the face properties will be identical as well, right? > So the question is, I guess: Does `M-q' does something to text > properties that we have to keep track of, or is it sufficient to just > hash the buffer contents to determine whether `M-q' did something? There are a couple of properties that have special meaning for fill.el functions, see there. However, I thought you are working on infrastructure that isn't supposed to be limited to what M-q does. Was I mistaken? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 11:29:46 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 15:29:46 +0000 Received: from localhost ([127.0.0.1]:42205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZ6s-0003GI-KO for submit@debbugs.gnu.org; Mon, 28 Mar 2016 11:29:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZ6n-0003G2-Aj for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:29:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akZ6d-0000wZ-NW for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:29:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akZ6d-0000wV-Jb; Mon, 28 Mar 2016 11:29:27 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4713 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akZ6c-0003PT-V9; Mon, 28 Mar 2016 11:29:27 -0400 Date: Mon, 28 Mar 2016 18:29:08 +0300 Message-Id: <83mvpiy62j.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Mon, 28 Mar 2016 13:27:49 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Date: Mon, 28 Mar 2016 13:27:49 +0200 > > I've now made a simple buffer hashing function (that does not take text > properties into account) to see how slow this would be. > > The following form > > (with-temp-buffer > (dotimes (i 10000) > (insert (make-string 100 ?k) "\n")) > (benchmark-run 1000 (buffer-hash))) > > takes 2.7 seconds (that's 1000 1MB buffers), and unsurprisingly > > (with-temp-buffer > (dotimes (i 10000000) > (insert (make-string 100 ?k) "\n")) > (benchmark-run 1 (progn (message "%s" (buffer-size) (buffer-hash))))) > > (which is 1 1GB buffer) takes the same amount of time. :-) > > (This is on a 2.7GHz i5 from like five years ago.) Optimized build or unoptimized? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 11:39:28 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 15:39:28 +0000 Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZGK-0003aw-5D for submit@debbugs.gnu.org; Mon, 28 Mar 2016 11:39:28 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:51219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZGI-0003al-CK for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:39:27 -0400 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 1akZGA-0002jB-R8; Mon, 28 Mar 2016 17:39:24 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWmnIgWEhQ2LygLCAf2 9e0FAwNqYVX5YNi4AAACSUlEQVQ4jXWTTW/cIBCGJ1uL84Iln81ky7mEOGc3QrkniDumq/n/P6Ev eL1qEvWVbCwezycD6f+ItJYixc66bGfSohU2je2gVilVtMhUbkBr38FWxU1exM1Gtg7Gw0Ls1Czm yWyn7VMMgqvtXJxUJXfQZazlr1ntstZqg5XtF/CtjiIidSIlTezs1FfWRCut6zWuRO0ZKiuKkdni 3bXioQ1QsXMV0WiId70pXYZYGY6YSfbNxt/Y8bCqiryNaRbDASYiIWsnvrk6HSCc0AXh68mxJy7C dzDxXEgNa6mefHUl7hms+oUgNRDDwqCBVNYdhKGRAa03ZDWP2ogMDeg5xkqq5qDpMdgljHo5A1gv 8ETCeTEUgs9pSfkJYNOTFOSFXzX5EHLKOZsGjChFpdSAOvy45KZmUYsgE2qAyQAEgPfYuguJqA6a q665bytSqo6px9hd5YCvxGiEVBvaXB2gpZCqm5XU8MnVgZeEHW++gdzA8sRw9RmEABB2sAdJHn94 xoRgtM7UQLhlpVGm4KiQ8DUSou3AGwDk61B9nYSCH5E/vBm2SzIOQ4fbgilpObzrZbdI4lCh23hS FNCr1OJ7rfPHZuCqVntZ0d0whiZYJC+zwjRYd11x7k2mv8OLmqgQbWaWfg2aSVuX88m3Fls71wP4 tuYniwoxchWu2kY4wGxTbfMgl7gD3135NP8EKEqVA/QYo3+Jfxxd9/H/9w6ac/x9iuoGjubiAD9+ xdeH4cf1BtL9KN6f4+t2fXjewXLfzx+X+Pp4kR38BRmy4Rg7+HvcAAAAAElFTkSuQmCC Date: Mon, 28 Mar 2016 17:39:18 +0200 In-Reply-To: <83twjqy6p7.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Mar 2016 18:15:32 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > The intervals do store the property itself, but I actually don't > understand why should you bother discerning between faces and the > other properties. If the buffer text is really unchanged, the face > properties will be identical as well, right? [...] > There are a couple of properties that have special meaning for fill.el > functions, see there. > > However, I thought you are working on infrastructure that isn't > supposed to be limited to what M-q does. Was I mistaken? Well, this is all kinda exploratory. What's feasible to do in general, and if nothing general can be done, can we still do something for `M-q'? In general: It would be really nice if `buffer-modified-p' really said whether the buffer was changed or not. That is, load a file, add an "a", delete the "a", and Emacs says "unchanged". If we had that mechanism, `M-q' would fall out naturally as a result. But as far as I can tell, this isn't really feasible because of the way we handle text properties: We consider some of them to change the buffer, and some of them to not change the buffer. And it doesn't look like we actually store that information in the text properties themselves. (Please correct me if I'm wrong or you have an idea for how to make this work.) So on to the specific problem of `M-q' again: If we think the general solution is a no go, would it still make sense to do the hash-the-buffer solution just for `M-q'? That is, does `M-q' ever change text properties in a way that we want maintained without changing the text itself? I think the answer to the last question is "no", but I'm not sure. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 11:40:05 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 15:40:05 +0000 Received: from localhost ([127.0.0.1]:42214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZGv-0003cI-Er for submit@debbugs.gnu.org; Mon, 28 Mar 2016 11:40:05 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:51238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZGt-0003c7-0o for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:40:03 -0400 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 1akZGq-0002jO-J0; Mon, 28 Mar 2016 17:40:02 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83mvpiy62j.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEVaUlgJAwX29fRAOT37 +/rp5+iclpkSDA4FAAHMyMr///8pIiYbFBj+/v11bnPh32FyAAACKUlEQVQ4jW3U4WsSYRwHcGW0 XnTEDiEfeGQvYg4yFl7CJLS9qsEO1otoggZCbG2sFSgSXjBix6D7QSJR6DgLX4gX+MDFZLD1ImQy tgmO0WtLyLElm+XfkJur7vG536uDz/N9vr+7F2cRiflYDFB3moKmVuOqWKuxsLUYdbvYhK7tjTUG RQZ0ojd/cOum5e/7uQvdpxoN32R0Ykj8r/uuoAOzqyYtAH0jJpD+IMPzIxMIr2AYvdkLOZKfEzBE roSIy1iuj896eYQB5NjPQ2qr1DQCZAcA5VilIN3Aez6BV16XX81TEF5wxCxWHmQ0eETBp0f8QLsp d+5KPqOg0ChH2r86CTmZoSDvt0baXBQkPkmtS8hGE38p26ESXxJpsDZ5FFUAEklCQW5XQLIQh0S0 Bwp+4TNuxNBywkZ3fHQLku2io6Isr9FbFTZ9EuaKSLG56fJxr1fCfUVIDOzQifTKUylx2SrJ69sp I2jq12nZXuIAPCcp0QD5GW3UUXFXAXEhpxG0ECnh4qqfj64SzQiduYS9L61L9h2i98DcRqvkKzm2 Cf3mhDzc3XdzXPwJA9dx1eOpFH+zCX5tweKAQwbeLe6Hs8gE3mz1B7NFOGDgRin1INDmZxgYHrt/ VZ21seWB9lun2npxi4Fg9vHdqdZtpkOfujdfv+bPTDAJ18Tx5PBmLdc9ZoDanfRQ+N+XOofubyI4 FMhQUK93ISfmiQFG6qdzeq/+98TZ/AGBbpG790tqcwAAAABJRU5ErkJggg== Date: Mon, 28 Mar 2016 17:39:58 +0200 In-Reply-To: <83mvpiy62j.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Mar 2016 18:29:08 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > Optimized build or unoptimized? Let's see... src/Makefile says "CFLAGS = -g3 -O2". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 11:52:43 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 15:52:43 +0000 Received: from localhost ([127.0.0.1]:42218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZT5-0003to-Kb for submit@debbugs.gnu.org; Mon, 28 Mar 2016 11:52:43 -0400 Received: from smtp22.acens.net ([86.109.99.146]:45444 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZT0-0003tV-48 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:52:38 -0400 X-CTCH-RefID: str=0001.0A0B0205.56F9533B.01F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Received: from qcore (79.153.146.151) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 56CC7975025CD800; Mon, 28 Mar 2016 15:52:27 +0000 From: =?utf-8?Q?=C3=93scar_Fuentes?= To: Lars Magne Ingebrigtsen Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> Date: Mon, 28 Mar 2016 17:52:26 +0200 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 28 Mar 2016 17:39:18 +0200") Message-ID: <87bn5y8urp.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: Eli Zaretskii , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Lars Magne Ingebrigtsen writes: [snip] > So on to the specific problem of `M-q' again: If we think the general > solution is a no go, would it still make sense to do the hash-the-buffer > solution just for `M-q'? That is, does `M-q' ever change text > properties in a way that we want maintained without changing the text > itself? I think the answer to the last question is "no", but I'm not > sure. To be precise, the question is not about *maintaining* the changed properties (nobody suggested to throw them away) but about marking the buffer as modified just because those properties [might have] changed. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 12:29:37 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 16:29:37 +0000 Received: from localhost ([127.0.0.1]:42245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aka2n-0004u2-O6 for submit@debbugs.gnu.org; Mon, 28 Mar 2016 12:29:37 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:52509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aka2i-0004tm-BK for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 12:29:32 -0400 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 1aka2c-00038I-4v; Mon, 28 Mar 2016 18:29:25 +0200 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?=D3scar?= Fuentes Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> <87bn5y8urp.fsf@wanadoo.es> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEVaUlgJAwX29fRAOT37 +/rp5+iclpkSDA4FAAHMyMr///8pIiYbFBj+/v11bnPh32FyAAACKUlEQVQ4jW3U4WsSYRwHcGW0 XnTEDiEfeGQvYg4yFl7CJLS9qsEO1otoggZCbG2sFSgSXjBix6D7QSJR6DgLX4gX+MDFZLD1ImQy tgmO0WtLyLElm+XfkJur7vG536uDz/N9vr+7F2cRiflYDFB3moKmVuOqWKuxsLUYdbvYhK7tjTUG RQZ0ojd/cOum5e/7uQvdpxoN32R0Ykj8r/uuoAOzqyYtAH0jJpD+IMPzIxMIr2AYvdkLOZKfEzBE roSIy1iuj896eYQB5NjPQ2qr1DQCZAcA5VilIN3Aez6BV16XX81TEF5wxCxWHmQ0eETBp0f8QLsp d+5KPqOg0ChH2r86CTmZoSDvt0baXBQkPkmtS8hGE38p26ESXxJpsDZ5FFUAEklCQW5XQLIQh0S0 Bwp+4TNuxNBywkZ3fHQLku2io6Isr9FbFTZ9EuaKSLG56fJxr1fCfUVIDOzQifTKUylx2SrJ69sp I2jq12nZXuIAPCcp0QD5GW3UUXFXAXEhpxG0ECnh4qqfj64SzQiduYS9L61L9h2i98DcRqvkKzm2 Cf3mhDzc3XdzXPwJA9dx1eOpFH+zCX5tweKAQwbeLe6Hs8gE3mz1B7NFOGDgRin1INDmZxgYHrt/ VZ21seWB9lun2npxi4Fg9vHdqdZtpkOfujdfv+bPTDAJ18Tx5PBmLdc9ZoDanfRQ+N+XOofubyI4 FMhQUK93ISfmiQFG6qdzeq/+98TZ/AGBbpG790tqcwAAAABJRU5ErkJggg== Date: Mon, 28 Mar 2016 18:29:21 +0200 In-Reply-To: <87bn5y8urp.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Mon, 28 Mar 2016 17:52:26 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: Eli Zaretskii , 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) =D3scar Fuentes writes: > Lars Magne Ingebrigtsen writes: > > [snip] > >> So on to the specific problem of `M-q' again: If we think the general >> solution is a no go, would it still make sense to do the hash-the-buffer >> solution just for `M-q'? That is, does `M-q' ever change text >> properties in a way that we want maintained without changing the text >> itself? I think the answer to the last question is "no", but I'm not >> sure. > > To be precise, the question is not about *maintaining* the changed > properties (nobody suggested to throw them away) but about marking the > buffer as modified just because those properties [might have] changed. I've been trying to `M-q' stuff in a handful of different modes, and there doesn't seem to be any text property changes at all, as far as I can see. (When the text doesn't change, that is.) So I could just commit the changes I've got here (the new `hash-buffer' function and the `M-q' changes, along with unit tests and doc fixes), and then we can see how this feels and whether there are any gotchas. And then ponder the more general issues later. Does that sound OK to everybody? --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 12:56:36 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 16:56:37 +0000 Received: from localhost ([127.0.0.1]:42266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akaSy-0007Df-8i for submit@debbugs.gnu.org; Mon, 28 Mar 2016 12:56:36 -0400 Received: from mout.gmx.net ([212.227.15.19]:64128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akXEU-00009y-SO for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 09:29:27 -0400 Received: from [193.147.107.1] by 3capp-gmx-bs57.server.lan (via HTTP); Mon, 28 Mar 2016 15:29:19 +0200 MIME-Version: 1.0 Message-ID: From: "Petros Travioli" To: "Andreas Schwab" , 13949@debbugs.gnu.org Subject: Aw: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy Content-Type: text/plain; charset=UTF-8 Date: Mon, 28 Mar 2016 15:29:19 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <87r3euhozp.fsf@linux-m68k.org> References: , <87r3euhozp.fsf@linux-m68k.org> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:ur+7Af7ePJm3voV6KJg76sOJyYH4Xj3xAApUyLlEX34 ardkQ/746jKN6KIUvSoG1HkVlbRe9jMht08Fx9rIrPexyrakBD yKYc3ntsr3gYRBjbipPDVQOmztYkSpgyOtFc9cdtWr/xRaUNi6 NvZyENSUWTuLkJJsM7qhZjl9Dja9vF5e5CConxJyzbr3WMQL/Y yLFOc+PBKGkUFf4psdYlhiufDi4CH5VyGwreQGMEkc6rKGrlzw IqXhXVa0A9r5iYRgkSO8mUMuAgg5auiPCjyLgT0Kt/VWSsehiY EDwBbQ= X-UI-Out-Filterresults: notjunk:1;V01:K0:JbsjjZ9uo8E=:mu5P05HXT2DGsA6vmpxyjW a9gieC6ZG9hjODK/hnSAhtswJ+DUQ+Z/L0t6i2HNbRjaCG2ObXf3VVX0aGcvnwn1ct2ydnAlF LYon6Ae3Td6KdOca1t8cvFXEDMxHU+bbTwKesThJr7ZMA+PLQp1UWnMdUtj/2LbOiJUg5K7B0 uuiquHd0rlNR0KJ/qSclX0W9M8sxhR4gJ9L0wbQEueMb1p/pIMCpMgZW7XezcxQTvzVABiaaP ZADyXhhLVYBnNP18whr3i3CfqZ58nRUPR/gFCT4X/libfmUUmDi4nSDOIfW+NdZGnxotxL8vU nF/tVKOl//PDXZoxTPLF0c1BCpN8Kq5P27s0Fu6OoUIxN1f+a4FyR8rHnowiN7o+g6O64zpIf lWpwJGz+cdRftv6K1mT7UQovDtnVyodPfxMW+2CtztZHUh5jPs0eZ2AaeNKsaClpo/NL3UboH ZDNSxTVLEw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 X-Mailman-Approved-At: Mon, 28 Mar 2016 12:56:34 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > > But that's exactly what happens when you are using hash functions to > > verify buffer equality, just with a more complicated mathematical > > formulation and at a slightly different scale. > > > > So don't use hash functions to a two-sided correct answer to test buffer > > equality. For a one-sided answer (if hash(x) != hash(y) then x != y), you > > are fine. > > There is a difference between a hash function and a cryptographic hash > function. An inportant property of a cryptographic hash function is the > avalanche effect, that means a small change in the plaintext will result > in a big change in the hash value. That makes such a hash function > suitable for the reverse condition x != y => hash(x) != hash(y), with a > very high probability of being true. > So far most old crypto functions have been broken. There is no doubt this will happen to any newer one sooner or later. If any single person would lose his work because of a random collision, this is an argument agains crypto hash functions. I am citing RFC 6151 (https://tools.ietf.org/html/rfc6151): "MD5 is no longer acceptable where collision resistance is required..." If the developers (I think, it was Eli who embraced the patch) are so sure about collision freedom: Eli, if you are so sure about MD5, please post your password MD5 hash here with login data and a consent that anyone is allowed to hack in. I do not want to go into prison. Then wait for, say, 1 week. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 12:56:37 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 16:56:37 +0000 Received: from localhost ([127.0.0.1]:42268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akaSy-0007Dh-TG for submit@debbugs.gnu.org; Mon, 28 Mar 2016 12:56:37 -0400 Received: from mout.gmx.net ([212.227.17.20]:57202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akYu0-0002vw-83 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:16:24 -0400 Received: from [193.147.107.1] by 3capp-gmx-bs67.server.lan (via HTTP); Mon, 28 Mar 2016 17:16:18 +0200 MIME-Version: 1.0 Message-ID: From: "Petros Travioli" To: 13949@debbugs.gnu.org Subject: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy Content-Type: text/plain; charset=UTF-8 Date: Mon, 28 Mar 2016 17:16:18 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:9HPOL/aOgaNlLI5sAQ0sd7dCHW1ZtfCKWL4LPUR68Jz sVdHN/Ebbh7z9tSzZYNUliALpOA47UoI7abywku5i8lHUeHlWg QAseqe+oGhCaJBUzmF1P9AG+7GU2j0LhS3QPiTpY2YHGZx65Qn +J2D9Ad6FRAg7T6IFSJiER2DsxmCcRUTGgHPTyYDoFuYC1hY43 WYAf2hRoKLromNzfjL0PpxshyUuliCSl4OW3NgLl/kOXMxqmF2 IVeK9vM3tf0YuUa7T2AN6M/N79zr8B0LARKsl6gZ/4PDkkC9lc FJbqYk= X-UI-Out-Filterresults: notjunk:1;V01:K0:Z+f7WO/h1+A=:bKlRR4Btf7zFKLDWDckR5g oK6NcGvxFq9HKh8AChRh/jRy3NBlJ6oyiYqNZKhMJyNN2fXP402eMy3vT0v69vrLZqnvlhbFX ynW3G+zDapoYdHghMHSIZ3oMNQjDdP2e4WBEH7bL+fRGNSrhgk4BLQaGwkfxNVTWXVqZBPLFK SAHzbxFFi7SlY8NhMEujFMX/OcCs7p/zg/TauTA9B4HnOGJEdbQStcc71BU1WrGSV72bVG5Z5 T6I166xchO9ss73rOi6NPgd8P35mikr88Bk0b4jzytz5Ha0aK9jpXl8iB9gQo/SAAVLBHWg9R iFHQex3OwqBBm2LGSIyDkFY3mh0DIqsh4E9yWcArfvL43EKL45oRT8zS0HqVtJTpcCi6kwdaC p1KGtCzQEss4XLf00UsIakPo+B6X/fEUliIhylkdKyXcIr//+lPgrXNnDkck7QRp8e6ZrAFlM ZP/2EeObaA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 X-Mailman-Approved-At: Mon, 28 Mar 2016 12:56:34 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) To any of the developers (especially Eli, who embraced the MD5 patch) who is so sure about collision freedom: Please be so kind to post your password MD5 hash here with login data and a consent that anyone is allowed to hack in. I do not want to go into jail. Then wait for, say, 1 week. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:04:47 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:04:47 +0000 Received: from localhost ([127.0.0.1]:42274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akaat-0000br-3E for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:04:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akaas-0000bf-67 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:04:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akaai-0004vU-9l for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:04:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akaai-0004vQ-6N; Mon, 28 Mar 2016 13:04:36 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4804 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akaah-00024B-D4; Mon, 28 Mar 2016 13:04:35 -0400 Date: Mon, 28 Mar 2016 20:04:16 +0300 Message-Id: <83h9fqy1nz.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Mon, 28 Mar 2016 18:29:21 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> <87bn5y8urp.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Cc: 13949@debbugs.gnu.org, Eli Zaretskii > Date: Mon, 28 Mar 2016 18:29:21 +0200 > > So I could just commit the changes I've got here (the new `hash-buffer' > function and the `M-q' changes, along with unit tests and doc fixes), > and then we can see how this feels and whether there are any gotchas. > > And then ponder the more general issues later. > > Does that sound OK to everybody? As optional behavior, yes. (Plus documentation, please.) From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:05:43 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:05:43 +0000 Received: from localhost ([127.0.0.1]:42278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akabn-0000dO-DV for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:05:43 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:53555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akabl-0000dG-Ph for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:05:42 -0400 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 1akabi-0003Rl-55; Mon, 28 Mar 2016 19:05:41 +0200 From: Lars Magne Ingebrigtsen To: "Petros Travioli" Subject: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy References: Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEX7+vUgHRoLCQji3NSN iIL////+//4JCAYHBgQEAgFEcs/RAAACSElEQVQ4jW2TPY/jIBCGZ4UvdVhzSk/jK0Gg1MaQ3JWR snFtadf5AW5Ie6tIJu1V9r+9gcRJ1trxF8zjdz7AhsVhZi90AQIyOM78O5MfBRAD7QHeAcg7CAGC rA9vVOAoc9DumHRLI53Nl8z8PJi8IQBaQbu3RubWaFvapdns6TbqLeZ4y6l0uXnJrMvpRrJ6AUSL ChUbq9TWZoSoUgHd1qiwGcfkz5axRUNEJqoZqM3yAEShYAaw1maNGcwcyLxpCHHqdQb2+RZLyqzk M4ACLCkJvoAPugEidBkFzwCX7wCKOKgSeKyupOsalCoz/lWhadkeG6HXFf+i0NTWbWzugz+DWtO8 3TWLuHzPgBhq2x8Ed87q4gYEKO2osfUO97DRtupuIN4oa9ojLrtAwYrfAKXMiYYcsVCCOyq7CQAs oAGCh1K6zCYBx6lQRAhCiFAW7oII0PCDwbtTWcGLCbgIMC/Wpsiq53eF00kT/ary3vOu6K7AXd34 MH3nT2HqwzptnXP4CZkQTn03EewjdmKVe43+0BW+8N01VDLzK6D5vve9L/gd0FVI5gP3/nRNPn5+ Xp1DAsH7okuhwiVNw2R9z/0EcBbC5TIkPxZ1zTGOSE4hjOOk6booQTDiq0l2ugXz3PMCoh+vyzD2 U5aYPwIMPiC6h8JGQl+kUOlMAEtEAZbgIxhjLMeYcX/Nb4MDxlZJEW0wLpf6LI3UltknMFbaSnlm TEqNv/YD/KuMo3/OZ2YqPFws9zJpYqrbAFuBh//JBiw3fAdwv/4D4BZXzkD5JOgAAAAASUVORK5C YII= Date: Mon, 28 Mar 2016 19:05:37 +0200 In-Reply-To: (Petros Travioli's message of "Mon, 28 Mar 2016 17:16:18 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) "Petros Travioli" writes: > To any of the developers (especially Eli, who embraced the MD5 patch) > who is so sure about collision freedom: > > Please be so kind to post your password MD5 hash here with login data > and a consent that anyone is allowed to hack in. I do not want to go > into jail. Then wait for, say, 1 week. This is irrelevant. Please take discussion of cryptographic hash collisions to the emacs-tangents mailing list. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:06:08 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:06:08 +0000 Received: from localhost ([127.0.0.1]:42282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akacC-0000eS-LL for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:06:08 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akacB-0000eE-Qa for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:06:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akac1-0005Ax-Qa for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:06:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akac1-0005As-NA; Mon, 28 Mar 2016 13:05:57 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4805 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akac0-00039V-U6; Mon, 28 Mar 2016 13:05:57 -0400 Date: Mon, 28 Mar 2016 20:05:38 +0300 Message-Id: <83fuvay1lp.fsf@gnu.org> From: Eli Zaretskii To: "Petros Travioli" In-reply-to: (travioli@gmx.de) Subject: Re: bug#13949: Aw: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy References: , <87r3euhozp.fsf@linux-m68k.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: "Petros Travioli" > Date: Mon, 28 Mar 2016 15:29:19 +0200 > > If the developers (I think, it was Eli who embraced the patch) are so sure about collision freedom: > > Eli, if you are so sure about MD5, please post your password MD5 hash here with login data and a consent that anyone is allowed to hack in. I do not want to go into prison. Then wait for, say, 1 week. Who is that "Eli" you are addressing this to? It's not me, I'm sure. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:06:51 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:06:51 +0000 Received: from localhost ([127.0.0.1]:42285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akacs-0000fO-UO for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:06:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akacr-0000fA-By for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:06:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akach-0005V8-F8 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:06:44 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akach-0005V4-Bc; Mon, 28 Mar 2016 13:06:39 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4807 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akacg-0003rE-H0; Mon, 28 Mar 2016 13:06:38 -0400 Date: Mon, 28 Mar 2016 20:06:20 +0300 Message-Id: <83d1qey1kj.fsf@gnu.org> From: Eli Zaretskii To: "Petros Travioli" In-reply-to: (travioli@gmx.de) Subject: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: "Petros Travioli" > Date: Mon, 28 Mar 2016 17:16:18 +0200 > > Eli, who embraced the MD5 patch I did? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:07:25 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:07:25 +0000 Received: from localhost ([127.0.0.1]:42290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akadQ-0000ge-6O for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:07:25 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:53621) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akadL-0000gU-6Y for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:07:22 -0400 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 1akadE-0003Sj-Qc; Mon, 28 Mar 2016 19:07:18 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> <87bn5y8urp.fsf@wanadoo.es> <83h9fqy1nz.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEX7+vUgHRoLCQji3NSN iIL////+//4JCAYHBgQEAgFEcs/RAAACSElEQVQ4jW2TPY/jIBCGZ4UvdVhzSk/jK0Gg1MaQ3JWR snFtadf5AW5Ie6tIJu1V9r+9gcRJ1trxF8zjdz7AhsVhZi90AQIyOM78O5MfBRAD7QHeAcg7CAGC rA9vVOAoc9DumHRLI53Nl8z8PJi8IQBaQbu3RubWaFvapdns6TbqLeZ4y6l0uXnJrMvpRrJ6AUSL ChUbq9TWZoSoUgHd1qiwGcfkz5axRUNEJqoZqM3yAEShYAaw1maNGcwcyLxpCHHqdQb2+RZLyqzk M4ACLCkJvoAPugEidBkFzwCX7wCKOKgSeKyupOsalCoz/lWhadkeG6HXFf+i0NTWbWzugz+DWtO8 3TWLuHzPgBhq2x8Ed87q4gYEKO2osfUO97DRtupuIN4oa9ojLrtAwYrfAKXMiYYcsVCCOyq7CQAs oAGCh1K6zCYBx6lQRAhCiFAW7oII0PCDwbtTWcGLCbgIMC/Wpsiq53eF00kT/ary3vOu6K7AXd34 MH3nT2HqwzptnXP4CZkQTn03EewjdmKVe43+0BW+8N01VDLzK6D5vve9L/gd0FVI5gP3/nRNPn5+ Xp1DAsH7okuhwiVNw2R9z/0EcBbC5TIkPxZ1zTGOSE4hjOOk6booQTDiq0l2ugXz3PMCoh+vyzD2 U5aYPwIMPiC6h8JGQl+kUOlMAEtEAZbgIxhjLMeYcX/Nb4MDxlZJEW0wLpf6LI3UltknMFbaSnlm TEqNv/YD/KuMo3/OZ2YqPFws9zJpYqrbAFuBh//JBiw3fAdwv/4D4BZXzkD5JOgAAAAASUVORK5C YII= Date: Mon, 28 Mar 2016 19:07:12 +0200 In-Reply-To: <83h9fqy1nz.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Mar 2016 20:04:16 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: Lars Magne Ingebrigtsen >> Cc: 13949@debbugs.gnu.org, Eli Zaretskii >> Date: Mon, 28 Mar 2016 18:29:21 +0200 >> >> So I could just commit the changes I've got here (the new `hash-buffer' >> function and the `M-q' changes, along with unit tests and doc fixes), >> and then we can see how this feels and whether there are any gotchas. >> >> And then ponder the more general issues later. >> >> Does that sound OK to everybody? > > As optional behavior, yes. With a variable to switch it off or on? I'm not quite sure I see the need, but I'm not against that... > (Plus documentation, please.) Of course. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:11:51 2016 Received: (at control) by debbugs.gnu.org; 28 Mar 2016 17:11:51 +0000 Received: from localhost ([127.0.0.1]:42302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akahj-0000nU-8r for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:11:51 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:53756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akahh-0000nL-T0 for control@debbugs.gnu.org; Mon, 28 Mar 2016 13:11:50 -0400 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 1akahf-0003VD-Df for control@debbugs.gnu.org; Mon, 28 Mar 2016 19:11:49 +0200 Date: Mon, 28 Mar 2016 19:11:46 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #13949 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 13949 fixed close 13949 25.2 From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:38:14 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:38:14 +0000 Received: from localhost ([127.0.0.1]:42323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akb7G-00033k-6n for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:38:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akb7B-00033U-3V for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:38:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akb71-00062z-1n for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:38:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akb70-00062i-V0; Mon, 28 Mar 2016 13:37:58 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4836 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akb6z-000502-TD; Mon, 28 Mar 2016 13:37:58 -0400 Date: Mon, 28 Mar 2016 20:37:39 +0300 Message-Id: <83a8liy04c.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Mon, 28 Mar 2016 19:07:12 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified 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> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> <87bn5y8urp.fsf@wanadoo.es> <83h9fqy1nz.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org > Date: Mon, 28 Mar 2016 19:07:12 +0200 > > Eli Zaretskii writes: > > >> Does that sound OK to everybody? > > > > As optional behavior, yes. > > With a variable to switch it off or on? Yes, I think that'd be good enough. > I'm not quite sure I see the need, but I'm not against that... You've heard here that some people think the current behavior is correct, so we should expect users to ask "how do I get the old behavior back?" We should have an answer for that. > > (Plus documentation, please.) > > Of course. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 13:45:42 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 17:45:42 +0000 Received: from localhost ([127.0.0.1]:42332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akbEU-0003Ew-Ai for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:45:42 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:54512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akbET-0003Em-3g for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 13:45:41 -0400 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 1akbEP-0003kG-HW; Mon, 28 Mar 2016 19:45:39 +0200 From: Lars Magne Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> <56F19203.5040501@ro.ru> <87a8lkd2bc.fsf@wanadoo.es> <83lh54ynol.fsf@gnu.org> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> <87bn5y8urp.fsf@wanadoo.es> <83h9fqy1nz.fsf@gnu.org> <83a8liy04c.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEVcUTz+/v6Mbk8CEAZv W0LSx7p4ZEooMyR32T31AAACQklEQVQ4jXXUMWvkMBAF4EERUp0ivXiI2TacAm6NMN76OMK1Qgil FWuz+vs39iZ2iotY3HxIb2ZkLz3/sOj5+eX9/f339pD1sv9kbfB36ENk0qRNASuXneFpgz+hB8Wa iEwC31N0pup9h8DNG4HbBJiUE1Xz2DGENzfLWWtlKAfX8gOWIay+pknO8lkxEuXygDBorqnQqFkp 8NhVPWDyU5F81lPm0m/8CB8GDa+SGXWMPvtCCo/wMBCcSpS0yS6zJ/MNUvVU7sVzRrH0BWGEK1XA O4F6QheY0AyBHTDZ63lUZANbKcuoUHuKJ8CA/JpViZltyp/w2iISqK4zBJwdv2BogMu66gwTOVn6 gtAjHEw1GTIS308YNtB1rjDO+2Y/q1pCuIFZ+zpLkPPGHg2GN8hUfZ1AnLw+qgrhFzBbrgRC4dkd De5AOesNXOGj3OUGjNJ3zSkXl+qRsSjgqtXIymNy48zf+sBHi5OXFiemcuwYZIezamaZlIJVZ7mS 4fusy5xxE6gHvMpZrWqtdFTcdTxAzpqaF4gy+U7qgBDhBYxROcsQ5wO6vEDN0d2oImE0nrAKJLrP Uh5fRzqhgVeiRjHDfZh+QgfuWkBlla50wrDDKMDxYqmdsACr1gIlXq7fICxyR60JJLiLXg9YgoC2 Ag71sqpv0EBmg23uLT6+jx1eMQroO5DkI9xh2cJDRzVPXW/v9aXt0/3b9/QhZnqypOViLtY8YNkB 0E92FKjJPjK6SN9ax8dY5QlO+w3++O/z//UPGJ/SD7LwYVoAAAAASUVORK5CYII= Date: Mon, 28 Mar 2016 19:45:37 +0200 In-Reply-To: <83a8liy04c.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Mar 2016 20:37:39 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> With a variable to switch it off or on? > > Yes, I think that'd be good enough. > >> I'm not quite sure I see the need, but I'm not against that... > > You've heard here that some people think the current behavior is > correct, so we should expect users to ask "how do I get the old > behavior back?" We should have an answer for that. Oh, I think I missed that. I thought they were only being confused about how cryptographic hashes worked? There were somebody who really wanted the "`M-q' didn't change anything, but I still want Emacs to say that the buffer was changed" behaviour back? In that case, I can add a variable for sure, but is that really the case? :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 14:17:50 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 18:17:50 +0000 Received: from localhost ([127.0.0.1]:42353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akbjZ-00044g-VT for submit@debbugs.gnu.org; Mon, 28 Mar 2016 14:17:50 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akbjY-00044U-H7 for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 14:17:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akbjP-00022c-Fd for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 14:17:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akbjP-00022Y-Cm; Mon, 28 Mar 2016 14:17:39 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4868 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akbjO-0008R3-Ia; Mon, 28 Mar 2016 14:17:39 -0400 Date: Mon, 28 Mar 2016 21:17:19 +0300 Message-Id: <837fgmxya8.fsf@gnu.org> From: Eli Zaretskii To: Lars Magne Ingebrigtsen In-reply-to: (message from Lars Magne Ingebrigtsen on Mon, 28 Mar 2016 19:45:37 +0200) Subject: Re: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified References: <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> <56F19203.5040501@ro.ru> <87a8lkd2bc.fsf@wanadoo.es> <83lh54ynol.fsf@gnu.org> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> <87bn5y8urp.fsf@wanadoo.es> <83h9fqy1nz.fsf@gnu.org> <83a8liy04c.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 13949 Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Lars Magne Ingebrigtsen > Cc: ofv@wanadoo.es, 13949@debbugs.gnu.org > Date: Mon, 28 Mar 2016 19:45:37 +0200 > > > You've heard here that some people think the current behavior is > > correct, so we should expect users to ask "how do I get the old > > behavior back?" We should have an answer for that. > > Oh, I think I missed that. I thought they were only being confused > about how cryptographic hashes worked? There were somebody who really > wanted the "`M-q' didn't change anything, but I still want Emacs to say > that the buffer was changed" behaviour back? > > In that case, I can add a variable for sure, but is that really the > case? :-) That's my understanding. And in any case, a change such as this one shouldn't be without a fire escape. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 28 15:03:29 2016 Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 19:03:29 +0000 Received: from localhost ([127.0.0.1]:42376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akcRl-0008VD-2f for submit@debbugs.gnu.org; Mon, 28 Mar 2016 15:03:29 -0400 Received: from mout.gmx.net ([212.227.17.21]:54346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akcRj-0008V1-9D for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 15:03:27 -0400 Received: from [193.147.107.1] by 3capp-gmx-bs19.server.lan (via HTTP); Mon, 28 Mar 2016 21:03:20 +0200 MIME-Version: 1.0 Message-ID: From: "Petros Travioli" To: eliz@gnu.org, 13949@debbugs.gnu.org Subject: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy Content-Type: text/plain; charset=UTF-8 Date: Mon, 28 Mar 2016 21:03:20 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <83d1qey1kj.fsf@gnu.org> References: , <83d1qey1kj.fsf@gnu.org> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:QpsIHhZ6skg68xbQ+8awK7oiyTMjqhPBZCs8S6i5Mqm mHd0UvpiynuBDVBHw7hhATE4Akt9wFHa5nOny+VJ2xi0dqUxvl N8brb9+2Tx5Sa6vW3TC8RUPw8BUO89t6imc2823/o1GP1EvvW9 UU+98kViv/25MjBP+3Txv32We66kKc38c0vvz49r4ypQ6GO6Fr 6IsBvBqEY67IAUrItuVTj/6/dSy53YQrM6LF13Jlz0j3UV7eN6 ZIzSySZ7Cly5/3ogpOXQTiijt9AFmrMwiynrrxmVebgLhenf3W B514Ls= X-UI-Out-Filterresults: notjunk:1;V01:K0:S5hs2/At+fA=:gDbwMxRimR0NedrXB8AjLm AtLYyAn1XVX9L02Non1RkiteXpFdR10skaWN80ueBMhLarxMiimdOPlLyrnN+G+1GBA+HSjGd 6SpTBUMXxhyaMH6xBqRjFbRGAH2bEwGr3ITl/dK/DUZAtygFZM600w/SxG7GjmOf5A0Y2U/9q BMOu/9ym7dU5obxNuE2f2ZLcKvU9Uar1Swn0rg+9b7yJdRgNkJuoCbKeslD2nWTaOB+nY3k8v 1jyqHV1HrWVcePH4Io0Z0+T9eKRumsccv87+M+FXcVo8aPcTL/OnMIavYbK9HatdI6HG9WJuU Omu9WdxEqqox9KIzCrq++55PRNjKvz29OicmA1MJ2xmSXRT8p+G4zBOXhUHTjOoOT95gZThY4 0/32DCpICSAjYo6WZ7CStCNp4twe1/3U+yDH1f9f4NyGpD7DGT2pApvmtEQlp9BuF8SVl7t2L +cgohZWDAg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13949 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > > Eli, who embraced the MD5 patch >=20 > I did? >=20 I'm sorry, you are right, you did not=2E It was the suggestion of =C3=93sc= ar on Sun, 27 Mar 2016 05:31:19 +0200 Anyhow, whoever introduces hashing is welcome to put his/her password hash= and login data here=2E With a consent that the account is alowed to be hac= ked=2E For 1 week=2E From unknown Sat Jun 14 19:38:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 26 Apr 2016 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 03 21:49:42 2016 Received: (at control) by debbugs.gnu.org; 4 Dec 2016 02:49:42 +0000 Received: from localhost ([127.0.0.1]:51761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDMs2-0004Js-AJ for submit@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDMrz-0004JW-G1 for control@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDMrs-0001yx-95 for control@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:34 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDMrs-0001yr-52 for control@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:32 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1cDMrr-0005b2-Kh; Sat, 03 Dec 2016 21:49:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22595.33851.293095.70553@gnu.org> Date: Sat, 3 Dec 2016 21:49:31 -0500 From: Glenn Morris To: control@debbugs.gnu.org Subject: Clean up predictable issues due to Emacs version number change X-Debbugs-No-Ack: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) # Ref: # http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00238.html # http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00692.html # http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01215.html # Some attempt has been made to check for things backported after the fact. # Erring on the side of a later version number seems preferable anyway. unarchive 10 fixed 10 26.1 notfixed 10 25.2 unarchive 96 fixed 96 26.1 notfixed 96 25.2 unarchive 1149 fixed 1149 26.1 notfixed 1149 25.2 unarchive 1150 fixed 1150 26.1 notfixed 1150 25.2 unarchive 2270 fixed 2270 26.1 notfixed 2270 25.2 unarchive 2405 fixed 2405 26.1 notfixed 2405 25.2 unarchive 2589 fixed 2589 26.1 notfixed 2589 25.2 unarchive 3137 fixed 3137 26.1 notfixed 3137 25.2 unarchive 3393 fixed 3393 26.1 notfixed 3393 25.2 unarchive 4589 fixed 4589 26.1 notfixed 4589 25.2 unarchive 4920 fixed 4920 26.1 notfixed 4920 25.2 unarchive 5001 fixed 5001 26.1 notfixed 5001 25.2 unarchive 5262 fixed 5262 26.1 notfixed 5262 25.2 unarchive 5305 fixed 5305 26.1 notfixed 5305 25.2 unarchive 5314 fixed 5314 26.1 notfixed 5314 25.2 unarchive 5479 fixed 5479 26.1 notfixed 5479 25.2 unarchive 5650 fixed 5650 26.1 notfixed 5650 25.2 unarchive 5661 fixed 5661 26.1 notfixed 5661 25.2 unarchive 5727 fixed 5727 26.1 notfixed 5727 25.2 unarchive 6817 fixed 6817 26.1 notfixed 6817 25.2 unarchive 7385 fixed 7385 26.1 notfixed 7385 25.2 unarchive 7522 fixed 7522 26.1 notfixed 7522 25.2 unarchive 7751 fixed 7751 26.1 notfixed 7751 25.2 unarchive 8634 fixed 8634 26.1 notfixed 8634 25.2 unarchive 8693 fixed 8693 26.1 notfixed 8693 25.2 unarchive 8925 fixed 8925 26.1 notfixed 8925 25.2 unarchive 9342 fixed 9342 26.1 notfixed 9342 25.2 unarchive 9730 fixed 9730 26.1 notfixed 9730 25.2 unarchive 10487 fixed 10487 26.1 notfixed 10487 25.2 unarchive 10540 fixed 10540 26.1 notfixed 10540 25.2 unarchive 10723 fixed 10723 26.1 notfixed 10723 25.2 unarchive 10794 fixed 10794 26.1 notfixed 10794 25.2 unarchive 10980 fixed 10980 26.1 notfixed 10980 25.2 unarchive 11357 fixed 11357 26.1 notfixed 11357 25.2 unarchive 11400 fixed 11400 26.1 notfixed 11400 25.2 unarchive 11788 fixed 11788 26.1 notfixed 11788 25.2 unarchive 12048 fixed 12048 26.1 notfixed 12048 25.2 unarchive 12377 fixed 12377 26.1 notfixed 12377 25.2 unarchive 12378 fixed 12378 26.1 notfixed 12378 25.2 unarchive 12636 fixed 12636 26.1 notfixed 12636 25.2 unarchive 12939 fixed 12939 26.1 notfixed 12939 25.2 unarchive 13269 fixed 13269 26.1 notfixed 13269 25.2 unarchive 13571 fixed 13571 26.1 notfixed 13571 25.2 unarchive 13745 fixed 13745 26.1 notfixed 13745 25.2 unarchive 13949 fixed 13949 26.1 notfixed 13949 25.2 unarchive 14256 fixed 14256 26.1 notfixed 14256 25.2 unarchive 14341 fixed 14341 26.1 notfixed 14341 25.2 unarchive 14484 fixed 14484 26.1 notfixed 14484 25.2 unarchive 14554 fixed 14554 26.1 notfixed 14554 25.2 unarchive 14577 fixed 14577 26.1 notfixed 14577 25.2 unarchive 14687 fixed 14687 26.1 notfixed 14687 25.2 unarchive 14844 fixed 14844 26.1 notfixed 14844 25.2 unarchive 14854 fixed 14854 26.1 notfixed 14854 25.2 unarchive 14915 fixed 14915 26.1 notfixed 14915 25.2 unarchive 14919 fixed 14919 26.1 notfixed 14919 25.2 unarchive 15021 fixed 15021 26.1 notfixed 15021 25.2 unarchive 15047 fixed 15047 26.1 notfixed 15047 25.2 unarchive 15171 fixed 15171 26.1 notfixed 15171 25.2 unarchive 15324 fixed 15324 26.1 notfixed 15324 25.2 unarchive 15445 fixed 15445 26.1 notfixed 15445 25.2 unarchive 15506 fixed 15506 26.1 notfixed 15506 25.2 unarchive 15909 fixed 15909 26.1 notfixed 15909 25.2 unarchive 16136 fixed 16136 26.1 notfixed 16136 25.2 unarchive 16200 fixed 16200 26.1 notfixed 16200 25.2 unarchive 16276 fixed 16276 26.1 notfixed 16276 25.2 unarchive 16294 fixed 16294 26.1 notfixed 16294 25.2 unarchive 16345 fixed 16345 26.1 notfixed 16345 25.2 unarchive 16390 fixed 16390 26.1 notfixed 16390 25.2 unarchive 16406 fixed 16406 26.1 notfixed 16406 25.2 unarchive 16483 fixed 16483 26.1 notfixed 16483 25.2 unarchive 16513 fixed 16513 26.1 notfixed 16513 25.2 unarchive 16579 fixed 16579 26.1 notfixed 16579 25.2 unarchive 16746 fixed 16746 26.1 notfixed 16746 25.2 unarchive 16891 fixed 16891 26.1 notfixed 16891 25.2 unarchive 16904 fixed 16904 26.1 notfixed 16904 25.2 unarchive 17039 fixed 17039 26.1 notfixed 17039 25.2 unarchive 17067 fixed 17067 26.1 notfixed 17067 25.2 unarchive 17119 fixed 17119 26.1 notfixed 17119 25.2 unarchive 17582 fixed 17582 26.1 notfixed 17582 25.2 unarchive 17707 fixed 17707 26.1 notfixed 17707 25.2 unarchive 17716 fixed 17716 26.1 notfixed 17716 25.2 unarchive 17738 fixed 17738 26.1 notfixed 17738 25.2 unarchive 17989 fixed 17989 26.1 notfixed 17989 25.2 unarchive 17999 fixed 17999 26.1 notfixed 17999 25.2 unarchive 18008 fixed 18008 26.1 notfixed 18008 25.2 unarchive 18024 fixed 18024 26.1 notfixed 18024 25.2 unarchive 18026 fixed 18026 26.1 notfixed 18026 25.2 unarchive 18028 fixed 18028 26.1 notfixed 18028 25.2 unarchive 18089 fixed 18089 26.1 notfixed 18089 25.2 unarchive 18092 fixed 18092 26.1 notfixed 18092 25.2 unarchive 18110 fixed 18110 26.1 notfixed 18110 25.2 unarchive 18202 fixed 18202 26.1 notfixed 18202 25.2 unarchive 18203 fixed 18203 26.1 notfixed 18203 25.2 unarchive 18204 fixed 18204 26.1 notfixed 18204 25.2 unarchive 18211 fixed 18211 26.1 notfixed 18211 25.2 unarchive 18279 fixed 18279 26.1 notfixed 18279 25.2 unarchive 18527 fixed 18527 26.1 notfixed 18527 25.2 unarchive 18587 fixed 18587 26.1 notfixed 18587 25.2 unarchive 18634 fixed 18634 26.1 notfixed 18634 25.2 unarchive 18635 fixed 18635 26.1 notfixed 18635 25.2 unarchive 18686 fixed 18686 26.1 notfixed 18686 25.2 unarchive 18692 fixed 18692 26.1 notfixed 18692 25.2 unarchive 18809 fixed 18809 26.1 notfixed 18809 25.2 unarchive 18810 fixed 18810 26.1 notfixed 18810 25.2 unarchive 18829 fixed 18829 26.1 notfixed 18829 25.2 unarchive 19114 fixed 19114 26.1 notfixed 19114 25.2 unarchive 19152 fixed 19152 26.1 notfixed 19152 25.2 unarchive 19209 fixed 19209 26.1 notfixed 19209 25.2 unarchive 19214 fixed 19214 26.1 notfixed 19214 25.2 unarchive 19215 fixed 19215 26.1 notfixed 19215 25.2 unarchive 19255 fixed 19255 26.1 notfixed 19255 25.2 unarchive 19368 fixed 19368 26.1 notfixed 19368 25.2 unarchive 19424 fixed 19424 26.1 notfixed 19424 25.2 unarchive 19497 fixed 19497 26.1 notfixed 19497 25.2 unarchive 19587 fixed 19587 26.1 notfixed 19587 25.2 unarchive 19638 fixed 19638 26.1 notfixed 19638 25.2 unarchive 19722 fixed 19722 26.1 notfixed 19722 25.2 unarchive 19754 fixed 19754 26.1 notfixed 19754 25.2 unarchive 19801 fixed 19801 26.1 notfixed 19801 25.2 unarchive 19851 fixed 19851 26.1 notfixed 19851 25.2 unarchive 20038 fixed 20038 26.1 notfixed 20038 25.2 unarchive 20158 fixed 20158 26.1 notfixed 20158 25.2 unarchive 20181 fixed 20181 26.1 notfixed 20181 25.2 unarchive 20304 fixed 20304 26.1 notfixed 20304 25.2 unarchive 20408 fixed 20408 26.1 notfixed 20408 25.2 unarchive 20460 fixed 20460 26.1 notfixed 20460 25.2 unarchive 20485 fixed 20485 26.1 notfixed 20485 25.2 unarchive 20520 fixed 20520 26.1 notfixed 20520 25.2 unarchive 20654 fixed 20654 26.1 notfixed 20654 25.2 unarchive 20702 fixed 20702 26.1 notfixed 20702 25.2 unarchive 20724 fixed 20724 26.1 notfixed 20724 25.2 unarchive 20878 fixed 20878 26.1 notfixed 20878 25.2 unarchive 21002 fixed 21002 26.1 notfixed 21002 25.2 unarchive 21014 fixed 21014 26.1 notfixed 21014 25.2 unarchive 21024 fixed 21024 26.1 notfixed 21024 25.2 unarchive 21155 fixed 21155 26.1 notfixed 21155 25.2 unarchive 21169 fixed 21169 26.1 notfixed 21169 25.2 unarchive 21171 fixed 21171 26.1 notfixed 21171 25.2 unarchive 21225 fixed 21225 26.1 notfixed 21225 25.2 unarchive 21231 fixed 21231 26.1 notfixed 21231 25.2 unarchive 21252 fixed 21252 26.1 notfixed 21252 25.2 unarchive 21269 fixed 21269 26.1 notfixed 21269 25.2 unarchive 21359 fixed 21359 26.1 notfixed 21359 25.2 unarchive 21427 fixed 21427 26.1 notfixed 21427 25.2 unarchive 21552 fixed 21552 26.1 notfixed 21552 25.2 unarchive 21576 fixed 21576 26.1 notfixed 21576 25.2 unarchive 21577 fixed 21577 26.1 notfixed 21577 25.2 unarchive 21601 fixed 21601 26.1 notfixed 21601 25.2 unarchive 21678 fixed 21678 26.1 notfixed 21678 25.2 unarchive 21679 fixed 21679 26.1 notfixed 21679 25.2 unarchive 21684 fixed 21684 26.1 notfixed 21684 25.2 unarchive 21706 fixed 21706 26.1 notfixed 21706 25.2 unarchive 21759 fixed 21759 26.1 notfixed 21759 25.2 unarchive 21851 fixed 21851 26.1 notfixed 21851 25.2 unarchive 21852 fixed 21852 26.1 notfixed 21852 25.2 unarchive 21853 fixed 21853 26.1 notfixed 21853 25.2 unarchive 21881 fixed 21881 26.1 notfixed 21881 25.2 unarchive 21936 fixed 21936 26.1 notfixed 21936 25.2 unarchive 21962 fixed 21962 26.1 notfixed 21962 25.2 unarchive 22117 fixed 22117 26.1 notfixed 22117 25.2 unarchive 22140 fixed 22140 26.1 notfixed 22140 25.2 unarchive 22170 fixed 22170 26.1 notfixed 22170 25.2 unarchive 22172 fixed 22172 26.1 notfixed 22172 25.2 unarchive 22227 fixed 22227 26.1 notfixed 22227 25.2 unarchive 22315 fixed 22315 26.1 notfixed 22315 25.2 unarchive 22325 fixed 22325 26.1 notfixed 22325 25.2 unarchive 22329 fixed 22329 26.1 notfixed 22329 25.2 unarchive 22348 fixed 22348 26.1 notfixed 22348 25.2 unarchive 22478 fixed 22478 26.1 notfixed 22478 25.2 unarchive 22530 fixed 22530 26.1 notfixed 22530 25.2 unarchive 22531 fixed 22531 26.1 notfixed 22531 25.2 unarchive 22576 fixed 22576 26.1 notfixed 22576 25.2 unarchive 22583 fixed 22583 26.1 notfixed 22583 25.2 unarchive 22586 fixed 22586 26.1 notfixed 22586 25.2 unarchive 22592 fixed 22592 26.1 notfixed 22592 25.2 unarchive 22594 fixed 22594 26.1 notfixed 22594 25.2 unarchive 22595 fixed 22595 26.1 notfixed 22595 25.2 unarchive 22596 fixed 22596 26.1 notfixed 22596 25.2 unarchive 22627 fixed 22627 26.1 notfixed 22627 25.2 unarchive 22632 fixed 22632 26.1 notfixed 22632 25.2 unarchive 22648 fixed 22648 26.1 notfixed 22648 25.2 unarchive 22664 fixed 22664 26.1 notfixed 22664 25.2 unarchive 22720 fixed 22720 26.1 notfixed 22720 25.2 unarchive 22724 fixed 22724 26.1 notfixed 22724 25.2 unarchive 22764 fixed 22764 26.1 notfixed 22764 25.2 unarchive 22799 fixed 22799 26.1 notfixed 22799 25.2 unarchive 22800 fixed 22800 26.1 notfixed 22800 25.2 unarchive 22814 fixed 22814 26.1 notfixed 22814 25.2 unarchive 22824 fixed 22824 26.1 notfixed 22824 25.2 unarchive 22827 fixed 22827 26.1 notfixed 22827 25.2 unarchive 22837 fixed 22837 26.1 notfixed 22837 25.2 unarchive 22841 fixed 22841 26.1 notfixed 22841 25.2 unarchive 22890 fixed 22890 26.1 notfixed 22890 25.2 unarchive 22928 fixed 22928 26.1 notfixed 22928 25.2 unarchive 22940 fixed 22940 26.1 notfixed 22940 25.2 unarchive 22964 fixed 22964 26.1 notfixed 22964 25.2 unarchive 22968 fixed 22968 26.1 notfixed 22968 25.2 unarchive 23020 fixed 23020 26.1 notfixed 23020 25.2 unarchive 23071 fixed 23071 26.1 notfixed 23071 25.2 unarchive 23116 fixed 23116 26.1 notfixed 23116 25.2 unarchive 23139 fixed 23139 26.1 notfixed 23139 25.2 unarchive 23159 fixed 23159 26.1 notfixed 23159 25.2 unarchive 23167 fixed 23167 26.1 notfixed 23167 25.2 unarchive 23262 fixed 23262 26.1 notfixed 23262 25.2 unarchive 23290 fixed 23290 26.1 notfixed 23290 25.2 unarchive 23374 fixed 23374 26.1 notfixed 23374 25.2 unarchive 23390 fixed 23390 26.1 notfixed 23390 25.2 unarchive 23401 fixed 23401 26.1 notfixed 23401 25.2 unarchive 23411 fixed 23411 26.1 notfixed 23411 25.2 unarchive 23459 fixed 23459 26.1 notfixed 23459 25.2 unarchive 23608 fixed 23608 26.1 notfixed 23608 25.2 unarchive 23703 fixed 23703 26.1 notfixed 23703 25.2 unarchive 23730 fixed 23730 26.1 notfixed 23730 25.2 unarchive 23829 fixed 23829 26.1 notfixed 23829 25.2 unarchive 23850 fixed 23850 26.1 notfixed 23850 25.2 unarchive 23863 fixed 23863 26.1 notfixed 23863 25.2 unarchive 23883 fixed 23883 26.1 notfixed 23883 25.2 unarchive 23914 fixed 23914 26.1 notfixed 23914 25.2 unarchive 23949 fixed 23949 26.1 notfixed 23949 25.2 unarchive 23998 fixed 23998 26.1 notfixed 23998 25.2 unarchive 24122 fixed 24122 26.1 notfixed 24122 25.2 unarchive 24133 fixed 24133 26.1 notfixed 24133 25.2 unarchive 24166 fixed 24166 26.1 notfixed 24166 25.2 unarchive 24257 fixed 24257 26.1 notfixed 24257 25.2 unarchive 24308 fixed 24308 26.1 notfixed 24308 25.2 unarchive 24432 fixed 24432 26.1 notfixed 24432 25.2 From unknown Sat Jun 14 19:38:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 01 Jan 2017 12:24:16 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator