From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Don't complain about changed file when it hasn't changed Date: Mon, 29 Aug 2016 10:50:04 -0400 Message-ID: References: <83oa4bbq5b.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472547209 32302 195.159.176.226 (30 Aug 2016 08:53:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 08:53:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 10:53:23 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1beenK-0007ku-0L for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 10:53:22 +0200 Original-Received: from localhost ([::1]:47842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beenK-0005HT-QN for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 04:53:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beelQ-0003D4-KD for emacs-devel@gnu.org; Tue, 30 Aug 2016 04:51:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beelM-0000pf-UU for emacs-devel@gnu.org; Tue, 30 Aug 2016 04:51:23 -0400 Original-Received: from [195.159.176.226] (port=34733 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beelM-0000oP-OD for emacs-devel@gnu.org; Tue, 30 Aug 2016 04:51:20 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1beNt3-0002r0-JZ for emacs-devel@gnu.org; Mon, 29 Aug 2016 16:50:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:XU5qgTQt7H/yvUPCU1joEJ0gpeY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206920 Archived-At: >> The patch below is supposed to change Emacs such that if the file's >> timestamp has changed, but the contents is still the same, it doesn't >> prompt the user about a supersession-threat. > Thanks. Can you describe the use case(s) where this is important? I think a common case nowadays is using Git's checkout and stash where you might change a file temporarily and then get back to its previous state (but with a different timestamp). Another I've bumped into several times is when you "touch " for purposes such as forcing a re-compilation. > Is it possible there are some use cases where this should be turned > off (in which case we might need a user option)? I couldn't think of any, but I'm not 100% positive that there can't be, that's why I'm asking for objections here ;-) > . compare-buffer-substrings is sensitive to case-fold-search value of > the current buffer, while we want the comparison case-sensitive Oh, indeed. I missed that it doesn't work like compare-strings. Thanks. > . need to bind coding-system-for-read to the encoding of the file's > buffer, otherwise you could get spurious false alarms, e.g. if the > file being checked was visited with non-default decoding (C-x RET c) Yes, I noticed that recently (tho I'm not worried about false alarms, but rather about silently considering that the file hasn't changed although it has). > . the file's buffer could be unibyte, in which case you want > insert-file-contents-literally, I think We could try to be more careful in this way, indeed. But AFAIK the only risk here is to flag a file as being changed when it hasn't, which is no worse than what we currently do (i.e. a false alarm), so I'm not sure it's worth the trouble. > . insert-file-contents could run out of memory, or hit some other > error, so I think you should catch any errors and consider the > check failed in that case Sure. > And, of course, please provide documentation for the feature. Not sure what there is to document, actually (I do have a NEWS entry for it, OTOH). Stefan