Don't complain about changed file when it hasn't changed

Don't complain about changed file when it hasn't changed

[Stefan Monnier]

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.

Any objection?


        Stefan


diff --git a/lisp/userlock.el b/lisp/userlock.el
index a0c55fd..9b45ef4 100644
--- a/lisp/userlock.el
+++ b/lisp/userlock.el
@@ -97,6 +97,20 @@ ask-user-about-lock-help
 
 (define-error 'file-supersession nil 'file-error)
 
+(defun userlock--check-content-unchanged (fn)
+  (save-restriction
+    (widen)
+    (let ((buf (current-buffer))
+          (start (point-min))
+          (end (point-max)))
+      (when (with-temp-buffer
+              (insert-file-contents fn)
+              (= 0 (compare-buffer-substrings
+                    buf start end
+                    (current-buffer) (point-min) (point-max))))
+        (set-visited-file-modtime)
+        'unchanged))))
+
 ;;;###autoload
 (defun ask-user-about-supersession-threat (fn)
   "Ask a user who is about to modify an obsolete buffer what to do.
@@ -106,30 +120,30 @@ ask-user-about-supersession-threat
 
 You can rewrite this to use any criterion you like to choose which one to do.
 The buffer in question is current when this function is called."
-  (discard-input)
-  (save-window-excursion
-    (let ((prompt
-	   (format "%s changed on disk; \
+  (unless (userlock--check-content-unchanged fn)
+    (discard-input)
+    (save-window-excursion
+      (let ((prompt
+             (format "%s changed on disk; \
 really edit the buffer? (y, n, r or C-h) "
-		   (file-name-nondirectory fn)))
-	  (choices '(?y ?n ?r ?? ?\C-h))
-	  answer)
-      (while (null answer)
-	(setq answer (read-char-choice prompt choices))
-	(cond ((memq answer '(?? ?\C-h))
-	       (ask-user-about-supersession-help)
-	       (setq answer nil))
-	      ((eq answer ?r)
-	       ;; Ask for confirmation if buffer modified
-	       (revert-buffer nil (not (buffer-modified-p)))
-	       (signal 'file-supersession
-		       (list "File reverted" fn)))
-	      ((eq answer ?n)
-	       (signal 'file-supersession
-		       (list "File changed on disk" fn)))))
-      (message
-       "File on disk now will become a backup file if you save these changes.")
-      (setq buffer-backed-up nil))))
+                     (file-name-nondirectory fn))))
+        (while
+            (let ((answer (read-char-choice prompt '(?y ?n ?r ?? ?\C-h))))
+              (cond ((memq answer '(?? ?\C-h))
+                     (ask-user-about-supersession-help)
+                     'repeat)
+                    ((eq answer ?r)
+                     ;; Ask for confirmation if buffer modified
+                     (revert-buffer nil (not (buffer-modified-p)))
+                     (signal 'file-supersession
+                             (list "File reverted" fn)))
+                    ((eq answer ?n)
+                     (signal 'file-supersession
+                             (list "File changed on disk" fn)))
+                    (t (null answer)))))
+        (message
+         "File on disk now will become a backup file if you save these changes.")
+        (setq buffer-backed-up nil)))))
 
 (defun ask-user-about-supersession-help ()
   (with-output-to-temp-buffer "*Help*"

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 3788 bytes --]

On 2016-08-28 20:29, Stefan Monnier wrote:
> 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.
> 
> Any objection?

This sounds like a neat feature! Are you sure you want (point-min) and (point-max) rather than 1 and (buffer-size), though?
Also, maybe this should be predicated on a test for small-enough files? For large-ish files, it could make things slow.

Clément.

> diff --git a/lisp/userlock.el b/lisp/userlock.el
> index a0c55fd..9b45ef4 100644
> --- a/lisp/userlock.el
> +++ b/lisp/userlock.el
> @@ -97,6 +97,20 @@ ask-user-about-lock-help
>  
>  (define-error 'file-supersession nil 'file-error)
>  
> +(defun userlock--check-content-unchanged (fn)
> +  (save-restriction
> +    (widen)
> +    (let ((buf (current-buffer))
> +          (start (point-min))
> +          (end (point-max)))
> +      (when (with-temp-buffer
> +              (insert-file-contents fn)
> +              (= 0 (compare-buffer-substrings
> +                    buf start end
> +                    (current-buffer) (point-min) (point-max))))
> +        (set-visited-file-modtime)
> +        'unchanged))))
> +
>  ;;;###autoload
>  (defun ask-user-about-supersession-threat (fn)
>    "Ask a user who is about to modify an obsolete buffer what to do.
> @@ -106,30 +120,30 @@ ask-user-about-supersession-threat
>  
>  You can rewrite this to use any criterion you like to choose which one to do.
>  The buffer in question is current when this function is called."
> -  (discard-input)
> -  (save-window-excursion
> -    (let ((prompt
> -	   (format "%s changed on disk; \
> +  (unless (userlock--check-content-unchanged fn)
> +    (discard-input)
> +    (save-window-excursion
> +      (let ((prompt
> +             (format "%s changed on disk; \
>  really edit the buffer? (y, n, r or C-h) "
> -		   (file-name-nondirectory fn)))
> -	  (choices '(?y ?n ?r ?? ?\C-h))
> -	  answer)
> -      (while (null answer)
> -	(setq answer (read-char-choice prompt choices))
> -	(cond ((memq answer '(?? ?\C-h))
> -	       (ask-user-about-supersession-help)
> -	       (setq answer nil))
> -	      ((eq answer ?r)
> -	       ;; Ask for confirmation if buffer modified
> -	       (revert-buffer nil (not (buffer-modified-p)))
> -	       (signal 'file-supersession
> -		       (list "File reverted" fn)))
> -	      ((eq answer ?n)
> -	       (signal 'file-supersession
> -		       (list "File changed on disk" fn)))))
> -      (message
> -       "File on disk now will become a backup file if you save these changes.")
> -      (setq buffer-backed-up nil))))
> +                     (file-name-nondirectory fn))))
> +        (while
> +            (let ((answer (read-char-choice prompt '(?y ?n ?r ?? ?\C-h))))
> +              (cond ((memq answer '(?? ?\C-h))
> +                     (ask-user-about-supersession-help)
> +                     'repeat)
> +                    ((eq answer ?r)
> +                     ;; Ask for confirmation if buffer modified
> +                     (revert-buffer nil (not (buffer-modified-p)))
> +                     (signal 'file-supersession
> +                             (list "File reverted" fn)))
> +                    ((eq answer ?n)
> +                     (signal 'file-supersession
> +                             (list "File changed on disk" fn)))
> +                    (t (null answer)))))
> +        (message
> +         "File on disk now will become a backup file if you save these changes.")
> +        (setq buffer-backed-up nil)))))
>  
>  (defun ask-user-about-supersession-help ()
>    (with-output-to-temp-buffer "*Help*"
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Daniel Colascione]

On 08/28/2016 08:36 PM, Clément Pit--Claudel wrote:
> On 2016-08-28 20:29, Stefan Monnier wrote:
>> 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.
>>
>> Any objection?
>
> This sounds like a neat feature! Are you sure you want (point-min)
> and
(point-max) rather than 1 and (buffer-size), though?

The code widens the buffer first.

> Also, maybe this should be predicated on a test for small-enough
files? For large-ish files, it could make things slow.

Memory is very fast these days, and compare-buffer-substrings is efficient.

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 947 bytes --]

On 2016-08-28 23:39, Daniel Colascione wrote:
> On 08/28/2016 08:36 PM, Clément Pit--Claudel wrote:
>> On 2016-08-28 20:29, Stefan Monnier wrote:
>>> 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.
>>>
>>> Any objection?
>>
>> This sounds like a neat feature! Are you sure you want (point-min)
>> and
> (point-max) rather than 1 and (buffer-size), though?
> 
> The code widens the buffer first.

That's right! It there an advantage to doing save-restriction + widen + point-min-point-max instead of using 1 and buffer-size?

>> Also, maybe this should be predicated on a test for small-enough
> files? For large-ish files, it could make things slow.
> 
> Memory is very fast these days, and compare-buffer-substrings is efficient.

I was concerned about insert-file-contents :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Michael Albinus]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

>>> Also, maybe this should be predicated on a test for small-enough
>>> files? For large-ish files, it could make things slow.
>>
>> Memory is very fast these days, and compare-buffer-substrings is efficient.
>
> I was concerned about insert-file-contents :)

Same concern here, for remote files. For large remote files I would
prefer a cksum call, if possible. But maybe we shall profile this, first.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> 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.
>> Any objection?
> This sounds like a neat feature! Are you sure you want (point-min) and
> (point-max) rather than 1 and (buffer-size), though?

I hate this assumption that point-min is 1 (so much so that my own
local Emacs has point-min set to 12345678).  I dreamed of changing this
long-standing wart so that point-min starts at 0 but it would require
changes in the redisplay code which I was not able to figure out.

[ For the curious, the error of using 1 became blindly obvious when
  I did some work on src/intervals.c where we have things like
  interval_start_pos (that's right: 15 lines to decide if it starts
  with 0 or with 1).  ]

> Also, maybe this should be predicated on a test for small-enough files?
> For large-ish files, it could make things slow.

Presumably, this code is not run often and is normally followed by
a prompt to the user, so its acceptable time scale is fairly large.

If we want to speed it up, I think a more promising approach would be
for "visited-modtime" to keep not just the modtime but also the file
size, so we would only perform the (potentially slow)
insert-file-contents with the new file has the same size as the old.

Michael added:
> Same concern here, for remote files.  For large remote files I would
> prefer a cksum call, if possible.  But maybe we shall profile this, first.

Of course we can't cksum the buffer without first encoding it.  Also,
this would require a cksum on files.  Is there a reliably-available
cksum operation we could run on files?


        Stefan


PS: I just noticed a problem with the patch.  I need to set
coding-system-for-read around the insert-file-contents call, otherwise
we might fail to notice when the only change to the file is that it uses
another coding system.

>> diff --git a/lisp/userlock.el b/lisp/userlock.el
>> index a0c55fd..9b45ef4 100644
>> --- a/lisp/userlock.el
>> +++ b/lisp/userlock.el
>> @@ -97,6 +97,20 @@ ask-user-about-lock-help
>> 
>> (define-error 'file-supersession nil 'file-error)
>> 
>> +(defun userlock--check-content-unchanged (fn)
>> +  (save-restriction
>> +    (widen)
>> +    (let ((buf (current-buffer))
>> +          (start (point-min))
>> +          (end (point-max)))
>> +      (when (with-temp-buffer
>> +              (insert-file-contents fn)
>> +              (= 0 (compare-buffer-substrings
>> +                    buf start end
>> +                    (current-buffer) (point-min) (point-max))))
>> +        (set-visited-file-modtime)
>> +        'unchanged))))
>> +
>> ;;;###autoload
>> (defun ask-user-about-supersession-threat (fn)
>> "Ask a user who is about to modify an obsolete buffer what to do.
>> @@ -106,30 +120,30 @@ ask-user-about-supersession-threat
>> 
>> You can rewrite this to use any criterion you like to choose which one to do.
>> The buffer in question is current when this function is called."
>> -  (discard-input)
>> -  (save-window-excursion
>> -    (let ((prompt
>> -	   (format "%s changed on disk; \
>> +  (unless (userlock--check-content-unchanged fn)
>> +    (discard-input)
>> +    (save-window-excursion
>> +      (let ((prompt
>> +             (format "%s changed on disk; \
>> really edit the buffer? (y, n, r or C-h) "
>> -		   (file-name-nondirectory fn)))
>> -	  (choices '(?y ?n ?r ?? ?\C-h))
>> -	  answer)
>> -      (while (null answer)
>> -	(setq answer (read-char-choice prompt choices))
>> -	(cond ((memq answer '(?? ?\C-h))
>> -	       (ask-user-about-supersession-help)
>> -	       (setq answer nil))
>> -	      ((eq answer ?r)
>> -	       ;; Ask for confirmation if buffer modified
>> -	       (revert-buffer nil (not (buffer-modified-p)))
>> -	       (signal 'file-supersession
>> -		       (list "File reverted" fn)))
>> -	      ((eq answer ?n)
>> -	       (signal 'file-supersession
>> -		       (list "File changed on disk" fn)))))
>> -      (message
>> -       "File on disk now will become a backup file if you save these changes.")
>> -      (setq buffer-backed-up nil))))
>> +                     (file-name-nondirectory fn))))
>> +        (while
>> +            (let ((answer (read-char-choice prompt '(?y ?n ?r ?? ?\C-h))))
>> +              (cond ((memq answer '(?? ?\C-h))
>> +                     (ask-user-about-supersession-help)
>> +                     'repeat)
>> +                    ((eq answer ?r)
>> +                     ;; Ask for confirmation if buffer modified
>> +                     (revert-buffer nil (not (buffer-modified-p)))
>> +                     (signal 'file-supersession
>> +                             (list "File reverted" fn)))
>> +                    ((eq answer ?n)
>> +                     (signal 'file-supersession
>> +                             (list "File changed on disk" fn)))
>> +                    (t (null answer)))))
>> +        (message
>> +         "File on disk now will become a backup file if you save these changes.")
>> +        (setq buffer-backed-up nil)))))
>> 
>> (defun ask-user-about-supersession-help ()
>> (with-output-to-temp-buffer "*Help*"
>> 
>> 

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sun, 28 Aug 2016 20:29:42 -0400
> 
> 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?  Is
it possible there are some use cases where this should be turned off
(in which case we might need a user option)?

Anyway, the proposed implementation misses a few subtleties, IMO:

 . compare-buffer-substrings is sensitive to case-fold-search value of
   the current buffer, while we want the comparison case-sensitive
 . 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)
 . the file's buffer could be unibyte, in which case you want
   insert-file-contents-literally, I think
 . 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

And, of course, please provide documentation for the feature.

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 29 Aug 2016 08:44:28 +0200
> Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
> 
> > I was concerned about insert-file-contents :)
> 
> Same concern here, for remote files. For large remote files I would
> prefer a cksum call, if possible. But maybe we shall profile this, first.

Do we have a file-cksum function?  If not, it will have to be
introduced first, and made to work with both local and remote files.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> 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 <file>" 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

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> Anyway, the proposed implementation misses a few subtleties, IMO:

Revised patch,


        Stefan


diff --git a/etc/NEWS b/etc/NEWS
index 1290fa4..cdabeda 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -213,6 +213,10 @@ In modes where form feed was treated as a whitespace character,
 It now deletes whitespace after the last form feed thus behaving the
 same as in modes where the character is not whitespace.
 
+** No more prompt about changed file when the file's content is unchanged.
+Instead of only checking the modification time, Emacs now also checks
+the file's actual content before prompting the user.
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 25.2
 
diff --git a/lisp/userlock.el b/lisp/userlock.el
index a0c55fd..2295184 100644
--- a/lisp/userlock.el
+++ b/lisp/userlock.el
@@ -97,6 +97,28 @@ ask-user-about-lock-help
 
 (define-error 'file-supersession nil 'file-error)
 
+(defun userlock--check-content-unchanged (fn)
+  (with-demoted-errors "Unchanged content check: %S"
+    (save-restriction
+      (widen)
+      (let ((buf (current-buffer))
+            (cs buffer-file-coding-system)
+            (start (point-min))
+            (end (point-max)))
+        ;; FIXME: To avoid a slow `insert-file-contents' on large or
+        ;; remote files, it'd be good to include file size in the
+        ;; "visited-modtime" check.
+        (when (with-temp-buffer
+                (let ((coding-system-for-read cs))
+                  (insert-file-contents fn))
+                (when (= (buffer-size) (- end start)) ;Minor optimization.
+                  (= 0 (let ((case-fold-search nil))
+                         (compare-buffer-substrings
+                          buf start end
+                          (current-buffer) (point-min) (point-max))))))
+          (set-visited-file-modtime)
+          'unchanged)))))
+
 ;;;###autoload
 (defun ask-user-about-supersession-threat (fn)
   "Ask a user who is about to modify an obsolete buffer what to do.
@@ -106,30 +128,30 @@ ask-user-about-supersession-threat
 
 You can rewrite this to use any criterion you like to choose which one to do.
 The buffer in question is current when this function is called."
-  (discard-input)
-  (save-window-excursion
-    (let ((prompt
-	   (format "%s changed on disk; \
+  (unless (userlock--check-content-unchanged fn)
+    (discard-input)
+    (save-window-excursion
+      (let ((prompt
+             (format "%s changed on disk; \
 really edit the buffer? (y, n, r or C-h) "
-		   (file-name-nondirectory fn)))
-	  (choices '(?y ?n ?r ?? ?\C-h))
-	  answer)
-      (while (null answer)
-	(setq answer (read-char-choice prompt choices))
-	(cond ((memq answer '(?? ?\C-h))
-	       (ask-user-about-supersession-help)
-	       (setq answer nil))
-	      ((eq answer ?r)
-	       ;; Ask for confirmation if buffer modified
-	       (revert-buffer nil (not (buffer-modified-p)))
-	       (signal 'file-supersession
-		       (list "File reverted" fn)))
-	      ((eq answer ?n)
-	       (signal 'file-supersession
-		       (list "File changed on disk" fn)))))
-      (message
-       "File on disk now will become a backup file if you save these changes.")
-      (setq buffer-backed-up nil))))
+                     (file-name-nondirectory fn))))
+        (while
+            (let ((answer (read-char-choice prompt '(?y ?n ?r ?? ?\C-h))))
+              (cond ((memq answer '(?? ?\C-h))
+                     (ask-user-about-supersession-help)
+                     'repeat)
+                    ((eq answer ?r)
+                     ;; Ask for confirmation if buffer modified
+                     (revert-buffer nil (not (buffer-modified-p)))
+                     (signal 'file-supersession
+                             (list "File reverted" fn)))
+                    ((eq answer ?n)
+                     (signal 'file-supersession
+                             (list "File changed on disk" fn)))
+                    (t (null answer)))))
+        (message
+         "File on disk now will become a backup file if you save these changes.")
+        (setq buffer-backed-up nil)))))
 
 (defun ask-user-about-supersession-help ()
   (with-output-to-temp-buffer "*Help*"

Re: Don't complain about changed file when it hasn't changed

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Do we have a file-cksum function?  If not, it will have to be
> introduced first, and made to work with both local and remote files.

Not that I'm aware of. cksum uses internally the crc32 algorithm. Maybe
we should extend secure_hash of fns.c for this algorithm.

Best regards, Michael.

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Aug 2016 12:01:55 -0400
> 
> > Anyway, the proposed implementation misses a few subtleties, IMO:
> 
> Revised patch,

Thanks.  I guess you decided not to bother about the unibyte buffer
case?

Re: Don't complain about changed file when it hasn't changed

[Davis Herring]

> Same concern here, for remote files. For large remote files I would
> prefer a cksum call, if possible. But maybe we shall profile this, first.

A very basic "checksum" would be to just use the file's size.  We could 
easily implement that and catch most modifications without any real I/O.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Don't complain about changed file when it hasn't changed

[Davis Herring]

> Thanks.  Can you describe the use case(s) where this is important?

I can name one common case: "git rebase", where frequently the file's 
original contents are (eventually) restored exactly.  (A non-interactive 
rebase does this when commits are moved on top of changes to other files.)

To me, avoiding the prompt is nice, but retaining the undo list is the 
important part.  (Thanks, Stefan!)  Should it be what is mentioned in NEWS?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 453 bytes --]

On 2016-08-29 13:42, Davis Herring wrote:
>> Same concern here, for remote files. For large remote files I would
>> prefer a cksum call, if possible. But maybe we shall profile this, first.
> 
> A very basic "checksum" would be to just use the file's size.  We could easily implement that and catch most modifications without any real I/O.

Does this work? Many changes don't affect file size, we we would still want to prompt the user, right?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Davis Herring <herring@lanl.gov>
> Date: Mon, 29 Aug 2016 11:50:43 -0600
> 
> > Thanks.  Can you describe the use case(s) where this is important?
> 
> I can name one common case: "git rebase", where frequently the file's 
> original contents are (eventually) restored exactly.  (A non-interactive 
> rebase does this when commits are moved on top of changes to other files.)

I don't understand why Git touches files it doesn't need to change.
It can (and does, AFAIK) compute the checksum of a file to know
whether it changed.

> To me, avoiding the prompt is nice, but retaining the undo list is the 
> important part.  (Thanks, Stefan!)  Should it be what is mentioned in NEWS?

AFAIU, the undo records are kept because you don't revert the buffer,
not because of the check.  You could refuse to revert with the current
code, and keep the undo information, right?

Re: Don't complain about changed file when it hasn't changed

[Davis Herring]

>> A very basic "checksum" would be to just use the file's size.  We could easily implement that and catch most modifications without any real I/O.
>
> Does this work? Many changes don't affect file size, we we would still want to prompt the user, right?

I merely meant

If the file size doesn't match, immediately rule the file "changed on 
disk" without paying for `insert-file-contents'.

as an optimization to prevent most of the I/O cost.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Don't complain about changed file when it hasn't changed

[Davis Herring]

> I don't understand why Git touches files it doesn't need to change.
> It can (and does, AFAIK) compute the checksum of a file to know
> whether it changed.

True that for a basic "git checkout new-branch" Git compares the (tree 
and blob) hashes to decide what files to touch.  However:

$ git init
Initialized empty Git repository in /tmp/grd/.git/
$ touch a b
$ git add a b
$ git commit -m "initial"
[master (root-commit) ad16e59] initial
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 a
  create mode 100644 b
$ echo >>a
$ git commit -am "newline: a"
[master 9023233] newline: a
  1 files changed, 1 insertions(+), 0 deletions(-)
$ echo >>a
$ git commit -am "newline 2: a"
[master eeb78ed] newline 2: a
  1 files changed, 1 insertions(+), 0 deletions(-)
$ git checkout -q HEAD^
$ echo >>b
$ git commit -am "newline: b"
[detached HEAD 2332479] newline: b
  1 files changed, 1 insertions(+), 0 deletions(-)
$ stat -c %y b
2016-08-29 13:15:46.820780908 -0600
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: newline: b
$ stat -c %y b
2016-08-29 13:16:04.538756145 -0600

As the output says, it "rewinds" your changes and reapplies them on top 
of the chosen commit.  This could be considered an artifact of "git 
rebase"'s implementation as a shell script on top of the other git 
commands, but given the possibility of merge conflicts to resolve it's 
not clear that it "ought" to be done entirely in-memory before updating 
only those files that need it on disk.

> AFAIU, the undo records are kept because you don't revert the buffer,
> not because of the check.  You could refuse to revert with the current
> code, and keep the undo information, right?

You could, but Emacs would be trusting you that the file really wasn't 
altered.  You could check yourself with `diff-buffer-with-file', but 
that's tedious; I find I usually just toss the undo information (by 
typing 'r' in response to the query).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> > Anyway, the proposed implementation misses a few subtleties, IMO:
>> Revised patch,
> Thanks.  I guess you decided not to bother about the unibyte buffer
> case?

Exactly.  If it doesn't work right, it shouldn't have serious
consequences, and for all I know, it might even happen to work right.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> To me, avoiding the prompt is nice, but retaining the undo list is the
> important part.  (Thanks, Stefan!)  Should it be what is mentioned in NEWS?

AFAIK the undo list was preserved (revert-buffer used to throw away the
undo list, but I changed that a few years ago).


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> I don't understand why Git touches files it doesn't need to change.
> It can (and does, AFAIK) compute the checksum of a file to know
> whether it changed.

Usually it changes them then reverts them.
E.g.:

    git stash
    git pull
    git stash pop

all the files modified locally but not in the pulled change will have
a new timestamp but the same old contents.  Since these are separate Git
invocations, I don't think it would be correct for Git to reset the
timestamp to some earlier value.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Rolf Ade]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Date: Sun, 28 Aug 2016 20:29:42 -0400
>> 
>> 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?

Version control.

I'm using fossil. It happens (often enough) that I switch branch and a
file. opened in my long running emacs session get modified on disk. I
work on other files of that branch and switch back. Now I modifiy the
buffer connected to that back and forth and get alerted: Buffer modfied
on disk.

While this is easily worked out (revert-buffer), it is an interuption,
an irritation.

The alert is only necessary, if buffer content and file content differ.
Often (very often) buffer content and file content differ, if their last
modification differ. But sometimes (and not only in theory, but in real
workflows) the last modification differ, but buffer content and file
content do not.

Re: Don't complain about changed file when it hasn't changed

[Andreas Schwab]

On Aug 30 2016, Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> I don't understand why Git touches files it doesn't need to change.
>> It can (and does, AFAIK) compute the checksum of a file to know
>> whether it changed.
>
> Usually it changes them then reverts them.
> E.g.:
>
>     git stash
>     git pull
>     git stash pop
>
> all the files modified locally but not in the pulled change will have
> a new timestamp but the same old contents.  Since these are separate Git
> invocations, I don't think it would be correct for Git to reset the
> timestamp to some earlier value.

It wouldn't be able to do that anyway, since there is no state recording
the earlier values.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Don't complain about changed file when it hasn't changed

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Michael added:
>> Same concern here, for remote files.  For large remote files I would
>> prefer a cksum call, if possible.  But maybe we shall profile this, first.
>
> Of course we can't cksum the buffer without first encoding it.  Also,
> this would require a cksum on files.  Is there a reliably-available
> cksum operation we could run on files?

We don't have crc32 on lisp level (this is what the cksum program
uses). But there is md5, maybe it could be used instead. I'm not so
familiar with hash algorithms, so I don't know whether this is good
enough.

>         Stefan

Best regards, Michael.

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 771 bytes --]



On 2016-08-29 09:17, Stefan Monnier wrote:
>>> 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.
>>> >> Any objection?

>> > This sounds like a neat feature! Are you sure you want (point-min) and
>> > (point-max) rather than 1 and (buffer-size), though?

> I hate this assumption that point-min is 1 (so much so that my own
> local Emacs has point-min set to 12345678).

Sorry, maybe you misunderstood me, or maybe I misunderstood you.  Where do you see an assumption that point-min is 1?
Also, why not just introduce a function buffer-min, instead of the (save-restriction) + (widen) dance?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> We don't have crc32 on lisp level (this is what the cksum program
> uses). But there is md5, maybe it could be used instead. I'm not so
> familiar with hash algorithms, so I don't know whether this is good
> enough.

crc32 is weak anyway.  A weaker check that *is* easily available is the
file's size.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> Also, why not just introduce a function buffer-min, instead of the
>  (save-restriction) + (widen) dance?

We could, yes.

Note that it wouldn't help us in the present case, since we will look
(via compare-buffer-substring) at the whole buffer's text, so we need to
widen anyway.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Rolf Ade <rolf@pointsman.de>
> Date: Tue, 30 Aug 2016 03:23:02 +0200
> 
> > Thanks.  Can you describe the use case(s) where this is important?
> 
> Version control.

If the only use case is version-controlled files, perhaps we should
enable this feature only for buffers that visit version-controlled
files?

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1.1: Type: text/plain, Size: 521 bytes --]

On 2016-08-30 11:01, Stefan Monnier wrote:
>> Also, why not just introduce a function buffer-min, instead of the
>>  (save-restriction) + (widen) dance?
> 
> We could, yes.
> 
> Note that it wouldn't help us in the present case, since we will look
> (via compare-buffer-substring) at the whole buffer's text, so we need to
> widen anyway.

I see, thanks! I didn't realize that these functions needed widening. Its documentation doesn't seem to mention it, nor its docstring. What about the attached patch?



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: 0001-Mention-that-compare-buffer-substrings-can-throw-arg.patch --]
[-- Type: text/x-diff; name="0001-Mention-that-compare-buffer-substrings-can-throw-arg.patch", Size: 1500 bytes --]

From d64d57cdee65775345fcd1511d2e1e9ac4539a42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Pit--Claudel?= <clement.pitclaudel@live.com>
Date: Tue, 30 Aug 2016 11:20:10 -0400
Subject: [PATCH] ; Mention that compare-buffer-substrings can throw
 args-out-of-range

* doc/lispref/text.texi: Mention args-out-of-range.
---
 doc/lispref/text.texi | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi
index 213eec9..9f2ca11 100644
--- a/doc/lispref/text.texi
+++ b/doc/lispref/text.texi
@@ -340,9 +340,11 @@ Comparing Text
 This function lets you compare two substrings of the same buffer or two
 different buffers.  The first three arguments specify one substring,
 giving a buffer (or a buffer name) and two positions within the
-buffer.  The last three arguments specify the other substring in the
-same way.  You can use @code{nil} for @var{buffer1}, @var{buffer2}, or
-both to stand for the current buffer.
+buffer.  If these positions are not in the accessible portion of the
+buffer, @code{compare-buffer-substrings} signals an
+@code{args-out-of-range} error.  The last three arguments specify the
+other substring in the same way.  You can use @code{nil} for
+@var{buffer1}, @var{buffer2}, or both to stand for the current buffer.
 
 The value is negative if the first substring is less, positive if the
 first is greater, and zero if they are equal.  The absolute value of
-- 
2.7.4


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 29 Aug 2016 10:50:04 -0400
> 
> >  . 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.

The documentation should state this exemption, lest users expect
unibyte buffers to get the same treatment.

> > 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).

From the ELisp manual:

 -- Function: ask-user-about-supersession-threat filename
     This function is used to ask a user how to proceed after an attempt
     to modify an buffer visiting file FILENAME when the file is newer
     than the buffer text.  Emacs detects this because the modification
     time of the file on disk is newer than the last save-time of the
     buffer.  This means some other program has probably altered the
     file.

Some of that will no longer be accurate once we install your changes.

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]

On 2016-08-30 11:12, Eli Zaretskii wrote:
>> From: Rolf Ade <rolf@pointsman.de>
>> Date: Tue, 30 Aug 2016 03:23:02 +0200
>>
>>> Thanks.  Can you describe the use case(s) where this is important?
>>
>> Version control.
> 
> If the only use case is version-controlled files, perhaps we should
> enable this feature only for buffers that visit version-controlled
> files?

Another case: a Makefile may generate a.x automatically from b.x.  If b.x is updated, a.x will be regenerated on the next run.  If a.x was already open in Emacs, Emacs will prompts if the user tries to change it, even if a.x didn't actually change as a result of the re-generation.  a.x is not likely to be version-controlled, since it's auto-generated.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> >  . 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.
> The documentation should state this exemption, lest users expect
> unibyte buffers to get the same treatment.

I don't know for a fact that it doesn't work in the unibyte case, actually.

>> Not sure what there is to document, actually (I do have a NEWS entry for
>> it, OTOH).

> From the ELisp manual:

>  -- Function: ask-user-about-supersession-threat filename
>      This function is used to ask a user how to proceed after an attempt
>      to modify an buffer visiting file FILENAME when the file is newer
>      than the buffer text.  Emacs detects this because the modification
>      time of the file on disk is newer than the last save-time of the
>      buffer.  This means some other program has probably altered the
>      file.

> Some of that will no longer be accurate once we install your changes.

I'll update that,


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>  -- Function: ask-user-about-supersession-threat filename
>      This function is used to ask a user how to proceed after an attempt
>      to modify an buffer visiting file FILENAME when the file is newer
>      than the buffer text.  Emacs detects this because the modification
>      time of the file on disk is newer than the last save-time of the
>      buffer.  This means some other program has probably altered the
>      file.

> Some of that will no longer be accurate once we install your changes.

Hmm... actually, this documentation is still valid, because it specifies
when the function is called (which is not changed by my patch) rather
than what the function does.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> I see, thanks! I didn't realize that these functions needed widening.

AFAIK all functions normally can only operate within the
current narrowing.  It's only when the reverse is true that it should
be documented.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Tue, 30 Aug 2016 11:23:31 -0400
> 
> I didn't realize that these functions needed widening. Its documentation doesn't seem to mention it, nor its docstring. What about the attached patch?

This is not specific to these functions, this is a universal rule in
Emacs: if you want to access a buffer position, you need to make sure
it's in the accessible region.

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Tue, 30 Aug 2016 11:34:13 -0400
> 
> Another case: a Makefile may generate a.x automatically from b.x.  If b.x is updated, a.x will be regenerated on the next run.  If a.x was already open in Emacs, Emacs will prompts if the user tries to change it, even if a.x didn't actually change as a result of the re-generation.  a.x is not likely to be version-controlled, since it's auto-generated.

This will cause much more trouble to the project that uses this
Makefile, because Make does only consider the time stamp.  The usual
solution for this (and we have it in the Emacs build procedure as
well) is to use the move-if-change script, or something similar.  That
script makes sure that the file doesn't get updated unless its
contents really changed.

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Aug 2016 11:44:54 -0400
> 
> >> >  . 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.
> > The documentation should state this exemption, lest users expect
> > unibyte buffers to get the same treatment.
> 
> I don't know for a fact that it doesn't work in the unibyte case, actually.

buffer-file-coding-system will be the local default, so a non-ASCII
file will be decoded.

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Aug 2016 11:46:36 -0400
> 
> >  -- Function: ask-user-about-supersession-threat filename
> >      This function is used to ask a user how to proceed after an attempt
> >      to modify an buffer visiting file FILENAME when the file is newer
> >      than the buffer text.  Emacs detects this because the modification
> >      time of the file on disk is newer than the last save-time of the
> >      buffer.  This means some other program has probably altered the
> >      file.
> 
> > Some of that will no longer be accurate once we install your changes.
> 
> Hmm... actually, this documentation is still valid, because it specifies
> when the function is called (which is not changed by my patch) rather
> than what the function does.

We are splitting hair.

The problematic place (for me) is the "modification time of the file
on disk is newer", which implies that this is the only test for the
detection of supersession-threat.

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 630 bytes --]

On 2016-08-30 12:11, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pit@gmail.com>
>> Date: Tue, 30 Aug 2016 11:23:31 -0400
>>
>> I didn't realize that these functions needed widening. Its documentation doesn't seem to mention it, nor its docstring. What about the attached patch?
> 
> This is not specific to these functions, this is a universal rule in
> Emacs: if you want to access a buffer position, you need to make sure
> it's in the accessible region.

Ok; I wasn't aware of this rule.  The documentation of buffer-substring mentions the error, so I though the patch would be useful.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Aug 2016 11:48:16 -0400
> 
> > I see, thanks! I didn't realize that these functions needed widening.
> 
> AFAIK all functions normally can only operate within the
> current narrowing.  It's only when the reverse is true that it should
> be documented.

Indeed.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> >> >  . 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.
>> > The documentation should state this exemption, lest users expect
>> > unibyte buffers to get the same treatment.
>> I don't know for a fact that it doesn't work in the unibyte case, actually.
> buffer-file-coding-system will be the local default,

How do you know?  IOW, which scenario are you thinking about?  I tried
find-file on a PDF file and find-file-literally on a non-ascii text file
and in both cases I get a buffer with buffer-file-coding-system set to
`no-conversion'.  And indeed, in my tests, the code I sent just
correctly detects that the file was not changed.

> so a non-ASCII file will be decoded.

Maybe in some cases it may not work, indeed.  My favorite way to fix
those would be to make sure buffer-file-coding-system is set to
something like `binary' when the buffer is unibyte.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> >  -- Function: ask-user-about-supersession-threat filename
>> >      This function is used to ask a user how to proceed after an attempt
>> >      to modify an buffer visiting file FILENAME when the file is newer
>> >      than the buffer text.  Emacs detects this because the modification
>> >      time of the file on disk is newer than the last save-time of the
>> >      buffer.  This means some other program has probably altered the
>> >      file.
>> 
>> > Some of that will no longer be accurate once we install your changes.
>> 
>> Hmm... actually, this documentation is still valid, because it specifies
>> when the function is called (which is not changed by my patch) rather
>> than what the function does.

> We are splitting hair.

> The problematic place (for me) is the "modification time of the file
> on disk is newer", which implies that this is the only test for the
> detection of supersession-threat.

No, it is the only test made before calling this function (indeed, the
function doesn't make any such test).  My patch doesn't affect this: the
only test performed before calling this function is still the
modtime test.

It's important to know where the test is performed because:

    This function is called automatically by Emacs on the proper
    occasions.  It exists so you can customize Emacs by redefining it.
    See the file @file{userlock.el} for the standard definition.

So if you want to "update the doc" here, we'd have to actually state
what the standard definition does (we currently don't do actually that).


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 30 Aug 2016 13:13:14 -0400
> 
> >> I don't know for a fact that it doesn't work in the unibyte case, actually.
> > buffer-file-coding-system will be the local default,
> 
> How do you know?  IOW, which scenario are you thinking about?

I did this:

  emacs -Q
  C-x b foo
  M-: (set-buffer-multibyte nil) RET
  M-: buffer-file-coding-system RET

This yields my default for buffer-file-coding-system.

> Maybe in some cases it may not work, indeed.  My favorite way to fix
> those would be to make sure buffer-file-coding-system is set to
> something like `binary' when the buffer is unibyte.

That'd be fine, I think.

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 30 Aug 2016 13:16:45 -0400
> 
> >> >  -- Function: ask-user-about-supersession-threat filename
> >> >      This function is used to ask a user how to proceed after an attempt
> >> >      to modify an buffer visiting file FILENAME when the file is newer
> >> >      than the buffer text.  Emacs detects this because the modification
> >> >      time of the file on disk is newer than the last save-time of the
> >> >      buffer.  This means some other program has probably altered the
> >> >      file.
> >> 
> >> > Some of that will no longer be accurate once we install your changes.
> >> 
> >> Hmm... actually, this documentation is still valid, because it specifies
> >> when the function is called (which is not changed by my patch) rather
> >> than what the function does.
> 
> > We are splitting hair.
> 
> > The problematic place (for me) is the "modification time of the file
> > on disk is newer", which implies that this is the only test for the
> > detection of supersession-threat.
> 
> No, it is the only test made before calling this function (indeed, the
> function doesn't make any such test).  My patch doesn't affect this: the
> only test performed before calling this function is still the
> modtime test.

That's because your additional test is in
ask-user-about-supersession-threat itself, which previously only asked
the question, while the test was elsewhere.

So, you would be found innocent in the court of law, but failing to
say that the default implementation of
ask-user-about-supersession-threat now includes an additional test,
and will answer automatically without asking the user in some cases,
is IMO hiding an important detail.  In particular, ...

> It's important to know where the test is performed because:
> 
>     This function is called automatically by Emacs on the proper
>     occasions.  It exists so you can customize Emacs by redefining it.
>     See the file @file{userlock.el} for the standard definition.
> 
> So if you want to "update the doc" here, we'd have to actually state
> what the standard definition does (we currently don't do actually that).

... indeed we should state that, because otherwise a naïve user will
not understand how come she lost this nice feature by just replacing a
function that is supposed to ask a question and be done.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> How do you know?  IOW, which scenario are you thinking about?

> I did this:

>   emacs -Q
>   C-x b foo
>   M-: (set-buffer-multibyte nil) RET
>   M-: buffer-file-coding-system RET

> This yields my default for buffer-file-coding-system.

Right, but that's not a file buffer, so
ask-user-about-supersession-threat won't be called there.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> So if you want to "update the doc" here, we'd have to actually state
>> what the standard definition does (we currently don't do actually that).

> ... indeed we should state that, because otherwise a naïve user will
> not understand how come she lost this nice feature by just replacing a
> function that is supposed to ask a question and be done.

OK, I can do that.

Of course, this begs another question: should the new test be in
ask-user-about-supersession-threat or in its caller?  I placed it in
ask-user-about-supersession-threat for no very good reason (tho I don't
see any strong reasons to move it to the caller either).


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Aug 2016 14:06:02 -0400
> 
> >> So if you want to "update the doc" here, we'd have to actually state
> >> what the standard definition does (we currently don't do actually that).
> 
> > ... indeed we should state that, because otherwise a naïve user will
> > not understand how come she lost this nice feature by just replacing a
> > function that is supposed to ask a question and be done.
> 
> OK, I can do that.

Thanks.

> Of course, this begs another question: should the new test be in
> ask-user-about-supersession-threat or in its caller?  I placed it in
> ask-user-about-supersession-threat for no very good reason (tho I don't
> see any strong reasons to move it to the caller either).

My preference would be to have the test in the caller, because I doubt
that anyone who replaces that function would want to lose the test.
But that preference is not very strong.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> My preference would be to have the test in the caller, because I doubt
> that anyone who replaces that function would want to lose the test.
> But that preference is not very strong.

How 'bout the patch below, then,


        Stefan


diff --git a/doc/lispref/buffers.texi b/doc/lispref/buffers.texi
index 740d7cf..e4ef4d5 100644
--- a/doc/lispref/buffers.texi
+++ b/doc/lispref/buffers.texi
@@ -669,8 +669,9 @@ Modification Time
 This function is used to ask a user how to proceed after an attempt to
 modify an buffer visiting file @var{filename} when the file is newer
 than the buffer text.  Emacs detects this because the modification
-time of the file on disk is newer than the last save-time of the
-buffer.  This means some other program has probably altered the file.
+time of the file on disk is newer than the last save-time and its contents
+have changed.
+This means some other program has probably altered the file.
 
 @kindex file-supersession
 Depending on the user's answer, the function may return normally, in
diff --git a/etc/NEWS b/etc/NEWS
index 1290fa4..cdabeda 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -213,6 +213,10 @@ In modes where form feed was treated as a whitespace character,
 It now deletes whitespace after the last form feed thus behaving the
 same as in modes where the character is not whitespace.
 
+** No more prompt about changed file when the file's content is unchanged.
+Instead of only checking the modification time, Emacs now also checks
+the file's actual content before prompting the user.
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 25.2
 
diff --git a/lisp/userlock.el b/lisp/userlock.el
index a0c55fd..1cfc3b9 100644
--- a/lisp/userlock.el
+++ b/lisp/userlock.el
@@ -97,6 +97,41 @@ ask-user-about-lock-help
 
 (define-error 'file-supersession nil 'file-error)
 
+(defun userlock--check-content-unchanged (fn)
+  (with-demoted-errors "Unchanged content check: %S"
+    ;; Even tho we receive `fn', we know that `fn' refers to the current
+    ;; buffer's file.
+    (cl-assert (equal fn (expand-file-name buffer-file-truename)))
+    ;; Note: rather than read the file and compare to the buffer, we could save
+    ;; the buffer and compare to the file, but for encrypted data this
+    ;; wouldn't work well (and would risk exposing the data).
+    (save-restriction
+      (widen)
+      (let ((buf (current-buffer))
+            (cs buffer-file-coding-system)
+            (start (point-min))
+            (end (point-max)))
+        ;; FIXME: To avoid a slow `insert-file-contents' on large or
+        ;; remote files, it'd be good to include file size in the
+        ;; "visited-modtime" check.
+        (when (with-temp-buffer
+                (let ((coding-system-for-read cs)
+                      (non-essential t))
+                  (insert-file-contents fn))
+                (when (= (buffer-size) (- end start)) ;Minor optimization.
+                  (= 0 (let ((case-fold-search nil))
+                         (compare-buffer-substrings
+                          buf start end
+                          (current-buffer) (point-min) (point-max))))))
+          (set-visited-file-modtime)
+          'unchanged)))))
+
+;;;###autoload
+(defun userlock--ask-user-about-supersession-threat (fn)
+  ;; Called from filelock.c.
+  (unless (userlock--check-content-unchanged fn)
+    (ask-user-about-supersession-threat fn)))
+
 ;;;###autoload
 (defun ask-user-about-supersession-threat (fn)
   "Ask a user who is about to modify an obsolete buffer what to do.
diff --git a/src/filelock.c b/src/filelock.c
index 2f92e0f..bde34e2 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -684,7 +684,7 @@ lock_file (Lisp_Object fn)
     if (!NILP (subject_buf)
 	&& NILP (Fverify_visited_file_modtime (subject_buf))
 	&& !NILP (Ffile_exists_p (fn)))
-      call1 (intern ("ask-user-about-supersession-threat"), fn);
+      call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
 
   }
 

Re: Don't complain about changed file when it hasn't changed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 02 Sep 2016 11:22:15 -0400
> 
> > My preference would be to have the test in the caller, because I doubt
> > that anyone who replaces that function would want to lose the test.
> > But that preference is not very strong.
> 
> How 'bout the patch below, then,

Looks good to me, thank you very much.

Re: Don't complain about changed file when it hasn't changed

[Joost Kremers]

On Fri, Sep 02 2016, Stefan Monnier wrote:
> diff --git a/doc/lispref/buffers.texi b/doc/lispref/buffers.texi
> index 740d7cf..e4ef4d5 100644
> --- a/doc/lispref/buffers.texi
> +++ b/doc/lispref/buffers.texi
> @@ -669,8 +669,9 @@ Modification Time
>  This function is used to ask a user how to proceed after an attempt to
>  modify an buffer visiting file @var{filename} when the file is newer

"an buffer" --> "a buffer" :)


-- 
Joost Kremers
Life has its moments

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> > My preference would be to have the test in the caller, because I doubt
>> > that anyone who replaces that function would want to lose the test.
>> > But that preference is not very strong.
>> How 'bout the patch below, then,
> Looks good to me, thank you very much.

Thanks, installed,


        Stefan

Re: Don't complain about changed file when it hasn't changed

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

>>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

SM> The patch below is supposed to change Emacs such that if the file's
SM> timestamp has changed, but the contents is still the same, it doesn't
SM> prompt the user about a supersession-threat.

Stefan, what is the performance impact of this change, and how often will that
cost be paid? And don't imagine "modern hardware, lots of memory", imagine
that I'm on an old laptop on a plane, and every erg of CPU power I lose means
time I can't spend coding while in flight.

If Emacs is going to be checking the entire buffer contents against disk
regularly, then I would prefer a customization option that makes it easy to
revert back to the previous behavior (which has always been perfectly fine for
me).

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

> Stefan, what is the performance impact of this change, and how often
> will that cost be paid?

If you look at the code, you'll see that it is only called when the
previous behavior would have been to prompt the user.

I'm sure you've already bumped into those prompts, but I'd be really
surprised if you've bumped into them frequently enough to be worried
about their impact on battery life.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

SM> If you look at the code, you'll see that it is only called when the
SM> previous behavior would have been to prompt the user.

OK, that is not so bad then.

SM> I'm sure you've already bumped into those prompts, but I'd be really
SM> surprised if you've bumped into them frequently enough to be worried about
SM> their impact on battery life.

If someone tells me that Santa Claus isn't real, I worry about the impact on
battery life.  It's my natural reaction to all things. :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Don't complain about changed file when it hasn't changed

[Andreas Röhler]

On 06.09.2016 19:52, John Wiegley wrote:
>>>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> SM> If you look at the code, you'll see that it is only called when the
> SM> previous behavior would have been to prompt the user.
>
> OK, that is not so bad then.
>
> SM> I'm sure you've already bumped into those prompts, but I'd be really
> SM> surprised if you've bumped into them frequently enough to be worried about
> SM> their impact on battery life.
>
> If someone tells me that Santa Claus isn't real, I worry about the impact on
> battery life.  It's my natural reaction to all things. :)
>

A smart solution would analyze from Emacs these cases and stop the 
prompting without reload/compare stuff.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> If someone tells me that Santa Claus isn't real, I worry about the impact on
>> battery life.  It's my natural reaction to all things. :)
> A smart solution would analyze from Emacs these cases and stop the prompting
> without reload/compare stuff.

You mean Emacs should check on its own whether Santa is real?
Indeed, that'd be much better.


        Stefan

RE: Don't complain about changed file when it hasn't changed

[Drew Adams]

> You mean Emacs should check on its own whether Santa is real?
> Indeed, that'd be much better.

Sick the butterfly on him, to see.

Re: Don't complain about changed file when it hasn't changed

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Stefan, what is the performance impact of this change, and how often
>> will that cost be paid?
>
>If you look at the code, you'll see that it is only called when the
>previous behavior would have been to prompt the user.
>
>I'm sure you've already bumped into those prompts, but I'd be really
>surprised if you've bumped into them frequently enough to be worried
>about their impact on battery life.

Stefan, I noticed you put a "FIXME" comment in the new code, about how it would be better to check the file size first.  That would obviously be a good optimization: most of the time -- like, 99% of the time -- if the file contents are different from the buffer contents, their sizes will differ as well, so it's an easy "early out" check that would allow us to avoid loading in the entire file contents in the vast majority of cases.

Since it's also fairly easy to do, I thought maybe there's some subtle reason you didn't do it.  In an earlier comment, you mention encrypted files (and of course perhaps compressed files are another case), where the file size on disk might differ from the buffer size even though the contents are actually "the same".

If those kinds of things were the reason you didn't code the early-out check, then do we have a canonical list anywhere of all possible "non-verbatim" buffer<->file relationships?  E.g., compressed, encrypted... what else?

It would be a shame not to have the optimization that would work fine in the majority of cases, but of course we need to make absolutely sure it's correct for all cases.  I'm not sure how difficult that would be, but thought maybe you'd considered that question, and I'd like to know how deep this rabbit hole goes.  (If it's not that deep, I'll address the FIXME.)

Your patch is below, for convenient reference.

Best regards,
-Karl

=============================================
git log --name-status 5a4bffb661^..5a4bffb661
=============================================

commit 5a4bffb6617a274ca19bc7f5c1b1ceb6345651ab
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Fri Sep 2 11:44:13 2016 -0400

    Check actual contents before promting about changed file
    
    * lisp/userlock.el (userlock--check-content-unchanged)
    (userlock--ask-user-about-supersession-threat): New functions.
    * src/filelock.c (lock_file): Use them to avoid spurious prompting.
    * doc/lispref/buffers.texi (Modification Time): Update doc of
    ask-user-about-supersession-threat.

M	doc/lispref/buffers.texi
M	etc/NEWS
M	lisp/userlock.el
M	src/filelock.c

================================
git diff 5a4bffb661^..5a4bffb661
================================

diff --git doc/lispref/buffers.texi doc/lispref/buffers.texi
index 740d7cf..e4ef4d5 100644
--- doc/lispref/buffers.texi
+++ doc/lispref/buffers.texi
@@ -669,8 +669,9 @@ Modification Time
 This function is used to ask a user how to proceed after an attempt to
 modify an buffer visiting file @var{filename} when the file is newer
 than the buffer text.  Emacs detects this because the modification
-time of the file on disk is newer than the last save-time of the
-buffer.  This means some other program has probably altered the file.
+time of the file on disk is newer than the last save-time and its contents
+have changed.
+This means some other program has probably altered the file.
 
 @kindex file-supersession
 Depending on the user's answer, the function may return normally, in
diff --git etc/NEWS etc/NEWS
index 18975cb..3092e9f 100644
--- etc/NEWS
+++ etc/NEWS
@@ -213,6 +213,10 @@ In modes where form feed was treated as a whitespace character,
 It now deletes whitespace after the last form feed thus behaving the
 same as in modes where the character is not whitespace.
 
+** No more prompt about changed file when the file's content is unchanged.
+Instead of only checking the modification time, Emacs now also checks
+the file's actual content before prompting the user.
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 25.2
 
diff --git lisp/userlock.el lisp/userlock.el
index a0c55fd..1cfc3b9 100644
--- lisp/userlock.el
+++ lisp/userlock.el
@@ -97,6 +97,41 @@ ask-user-about-lock-help
 
 (define-error 'file-supersession nil 'file-error)
 
+(defun userlock--check-content-unchanged (fn)
+  (with-demoted-errors "Unchanged content check: %S"
+    ;; Even tho we receive `fn', we know that `fn' refers to the current
+    ;; buffer's file.
+    (cl-assert (equal fn (expand-file-name buffer-file-truename)))
+    ;; Note: rather than read the file and compare to the buffer, we could save
+    ;; the buffer and compare to the file, but for encrypted data this
+    ;; wouldn't work well (and would risk exposing the data).
+    (save-restriction
+      (widen)
+      (let ((buf (current-buffer))
+            (cs buffer-file-coding-system)
+            (start (point-min))
+            (end (point-max)))
+        ;; FIXME: To avoid a slow `insert-file-contents' on large or
+        ;; remote files, it'd be good to include file size in the
+        ;; "visited-modtime" check.
+        (when (with-temp-buffer
+                (let ((coding-system-for-read cs)
+                      (non-essential t))
+                  (insert-file-contents fn))
+                (when (= (buffer-size) (- end start)) ;Minor optimization.
+                  (= 0 (let ((case-fold-search nil))
+                         (compare-buffer-substrings
+                          buf start end
+                          (current-buffer) (point-min) (point-max))))))
+          (set-visited-file-modtime)
+          'unchanged)))))
+
+;;;###autoload
+(defun userlock--ask-user-about-supersession-threat (fn)
+  ;; Called from filelock.c.
+  (unless (userlock--check-content-unchanged fn)
+    (ask-user-about-supersession-threat fn)))
+
 ;;;###autoload
 (defun ask-user-about-supersession-threat (fn)
   "Ask a user who is about to modify an obsolete buffer what to do.
diff --git src/filelock.c src/filelock.c
index 2f92e0f..bde34e2 100644
--- src/filelock.c
+++ src/filelock.c
@@ -684,7 +684,7 @@ lock_file (Lisp_Object fn)
     if (!NILP (subject_buf)
 	&& NILP (Fverify_visited_file_modtime (subject_buf))
 	&& !NILP (Ffile_exists_p (fn)))
-      call1 (intern ("ask-user-about-supersession-threat"), fn);
+      call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
 
   }
 

Re: Don't complain about changed file when it hasn't changed

[Paul Eggert]

On 09/06/2016 02:41 PM, Karl Fogel wrote:
> E.g., compressed, encrypted... what else?

Using some coding system other than Emacs native coding, e.g., CRLF 
instead of LF.

Re: Don't complain about changed file when it hasn't changed

[Karl Fogel]

Paul Eggert <eggert@cs.ucla.edu> writes:
>On 09/06/2016 02:41 PM, Karl Fogel wrote:
>> E.g., compressed, encrypted... what else?
>
>Using some coding system other than Emacs native coding, e.g., CRLF
>instead of LF.

Oy.  Right.

This list of exceptions is getting long... and yet the early-out check is so tempting.  Sigh.

Re: Don't complain about changed file when it hasn't changed

[Karl Fogel]

I wrote:
>Paul Eggert <eggert@cs.ucla.edu> wrote:
>>On 09/06/2016 02:41 PM, Karl Fogel wrote:
>>> E.g., compressed, encrypted... what else?
>>
>>Using some coding system other than Emacs native coding, e.g., CRLF
>>instead of LF.
>
>Oy.  Right.
>
>This list of exceptions is getting long... and yet the early-out check is so tempting.  Sigh.

I think what I'm wishing for is a function `buffer-file-verbatim-correspondence-p' (better names welcome).  Iff the function returns non-nil, then we can do the early-out check.

Is there anything in Emacs already that encapsulates the knowledge such a function would need, or is this what the consultants like to call a "green field opportunity"?

Re: Don't complain about changed file when it hasn't changed

[Davis Herring]

> This list of exceptions is getting long... and yet the early-out check is so tempting.  Sigh.

You just remember the file's size as well as its modtime when visiting 
it -- don't compare to the buffer's size at all.  (I thought I had 
mentioned this earlier in the thread...)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Don't complain about changed file when it hasn't changed

[Karl Fogel]

Davis Herring <herring@lanl.gov> writes:
>You just remember the file's size as well as its modtime when visiting
>it -- don't compare to the buffer's size at all.  (I thought I had
>mentioned this earlier in the thread...)

Oh -- remember the "true" size (that is, the unencrypted/uncompressed/unwhatevered) size of the file at the moment when it is first visited?

As long as we're doing that, why not just remember the md5sum of the original content too?  Then if the file size is the same, we can just compute the md5sum of current buffer contents and compare against the saved md5sum.

Re: Don't complain about changed file when it hasn't changed

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 190 bytes --]

On 2016-09-06 18:21, Karl Fogel wrote:
> As long as we're doing that, why not just remember the md5sum of the original content too? 

That could be costly, for relatively small gains.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> You just remember the file's size as well as its modtime when visiting
>> it -- don't compare to the buffer's size at all.  (I thought I had
>> mentioned this earlier in the thread...)
> Oh -- remember the "true" size (that is, the
> unencrypted/uncompressed/unwhatevered) size of the file at the moment when
> it is first visited?

Yes, that's what my FIXME comment was referring to.

Comparing the buffer's size and the file's size would miss too many case
and would be too brittle for my taste (there are many different ways to
modify the data on the way between the file and the buffer).

> As long as we're doing that, why not just remember the md5sum of the
> original content too?

Cause it'd slow down a common case, compared to this
ask-user-about-supersession-threat which is used very rarely?


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Oh -- remember the "true" size (that is, the
>> unencrypted/uncompressed/unwhatevered) size of the file at the moment when
>> it is first visited?
>
>Yes, that's what my FIXME comment was referring to.
>
>Comparing the buffer's size and the file's size would miss too many case
>and would be too brittle for my taste (there are many different ways to
>modify the data on the way between the file and the buffer).

*nod*  Makes sense.  The risks here outweigh the potential win, I think.

>> As long as we're doing that, why not just remember the md5sum of the
>> original content too?
>
>Cause it'd slow down a common case, compared to this
>ask-user-about-supersession-threat which is used very rarely?

Oh, the extra expense of computing the md5sum at initial find-file time?  Hmmm... Fair enough, yeah.  I haven't profiled it, and don't think this is important enough to be worth making those measurements.  Let's leave things as they are.

Re: Don't complain about changed file when it hasn't changed

[Andreas Röhler]

On 07.09.2016 18:49, Karl Fogel wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>> Oh -- remember the "true" size (that is, the
>>> unencrypted/uncompressed/unwhatevered) size of the file at the moment when
>>> it is first visited?
>> Yes, that's what my FIXME comment was referring to.
>>
>> Comparing the buffer's size and the file's size would miss too many case
>> and would be too brittle for my taste (there are many different ways to
>> modify the data on the way between the file and the buffer).
> *nod*  Makes sense.  The risks here outweigh the potential win, I think.
>
>>> As long as we're doing that, why not just remember the md5sum of the
>>> original content too?
>> Cause it'd slow down a common case, compared to this
>> ask-user-about-supersession-threat which is used very rarely?
> Oh, the extra expense of computing the md5sum at initial find-file time?  Hmmm... Fair enough, yeah.  I haven't profiled it, and don't think this is important enough to be worth making those measurements.  Let's leave things as they are.
>

It might be helpful to consider, list and sort circumstances where 
avoiding the prompt is at stake.
  As running "touch" to trigger a re-compile was mentioned - why not 
have a command which disables the prompting just for this.

Re: Don't complain about changed file when it hasn't changed

[Karl Fogel]

Andreas Röhler <andreas.roehler@online.de> writes:
>It might be helpful to consider, list and sort circumstances where
>avoiding the prompt is at stake.
> As running "touch" to trigger a re-compile was mentioned - why not
>have a command which disables the prompting just for this.

Perhaps `dired-do-touch' should just also update the recorded time-stamp of the corresponding buffer (if any)?

There are other ways people touch files, but this would cover one way.

Re: Don't complain about changed file when it hasn't changed

[Rolf Ade]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 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.

What happend to this? Got it lost over the long discussion, that the
details, are, well, in the fine print?

I'd still love to have such a thing.

Re: Don't complain about changed file when it hasn't changed

[Stefan Monnier]

>> 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.
> What happend to this?

AFAIK it's in Emacs's master branch.


        Stefan

Re: Don't complain about changed file when it hasn't changed

[Rolf Ade]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> 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.
>> What happend to this?
>
> AFAIK it's in Emacs's master branch.

Great! And a big thank you, for stepping forward with this.

(I looked throu NEWS on master, before asking here, but somehow missed
the related entry (in "Editing Changes in Emacs 26.1"):

** No more prompt about changed file when the file's content is unchanged.
Instead of only checking the modification time, Emacs now also checks
the file's actual content before prompting the user.

)