From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs Subject: bug#49893: [PATCH] Reset mtime of a reverted buffer Date: Thu, 05 Aug 2021 19:54:03 +0300 Message-ID: <7dc543c6f2294f48b5ff11f2274b983b2e3ce03e.camel@yandex.ru> References: <40b594e36f8d8d8b200b91238d2208c8d25fd2c9.camel@yandex.ru> <838s1fkfvj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32331"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.40.3 Cc: 49893@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 05 18:55:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBgeM-0008D8-CD for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Aug 2021 18:55:18 +0200 Original-Received: from localhost ([::1]:44794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBgeK-0006qz-Es for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Aug 2021 12:55:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBge6-0006qe-Tz for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2021 12:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36720) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mBge6-0005xB-Ko for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2021 12:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mBge6-0002xe-HF for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2021 12:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Aug 2021 16:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49893 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 49893-submit@debbugs.gnu.org id=B49893.162818245311318 (code B ref 49893); Thu, 05 Aug 2021 16:55:02 +0000 Original-Received: (at 49893) by debbugs.gnu.org; 5 Aug 2021 16:54:13 +0000 Original-Received: from localhost ([127.0.0.1]:48263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBgdI-0002wU-Ok for submit@debbugs.gnu.org; Thu, 05 Aug 2021 12:54:13 -0400 Original-Received: from forward101p.mail.yandex.net ([77.88.28.101]:40464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBgdG-0002wH-Qy for 49893@debbugs.gnu.org; Thu, 05 Aug 2021 12:54:11 -0400 Original-Received: from forward103q.mail.yandex.net (forward103q.mail.yandex.net [IPv6:2a02:6b8:c0e:50:0:640:b21c:d009]) by forward101p.mail.yandex.net (Yandex) with ESMTP id 005A032830D6; Thu, 5 Aug 2021 19:54:04 +0300 (MSK) Original-Received: from vla5-53b4ceaf8148.qloud-c.yandex.net (vla5-53b4ceaf8148.qloud-c.yandex.net [IPv6:2a02:6b8:c18:341a:0:640:53b4:ceaf]) by forward103q.mail.yandex.net (Yandex) with ESMTP id EFFE661E0004; Thu, 5 Aug 2021 19:54:03 +0300 (MSK) Original-Received: from vla5-3832771863b8.qloud-c.yandex.net (vla5-3832771863b8.qloud-c.yandex.net [2a02:6b8:c18:3417:0:640:3832:7718]) by vla5-53b4ceaf8148.qloud-c.yandex.net (mxback/Yandex) with ESMTP id jsOgDImU31-s3ISaPoh; Thu, 05 Aug 2021 19:54:03 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1628182443; bh=rtntcs/DS+qyrPmJRFuD/JB5znHXNnqcAJFePth1ivg=; h=In-Reply-To:References:Date:To:From:Subject:Message-ID:Cc; b=KsW0z7pz7lyVjDIM5iuYmyiIS5iAvjveUH5vHl5/Aa1XOIJTLfFvnagjLeY4/UXgn HV9zuuUVObqpxJBun79eGdbr4QJNIhScbbqZi1hfw7ja1vnsZj83RhAAzG5SgeUOm7 86gML2rzGtcP9F9tjs3kqfVy0D01sp9VeuI5FYOc= Authentication-Results: vla5-53b4ceaf8148.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by vla5-3832771863b8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id hOdCrGQPDL-s3JOmbIW; Thu, 05 Aug 2021 19:54:03 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <838s1fkfvj.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211253 Archived-At: On Thu, 2021-08-05 at 19:36 +0300, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Date: Thu, 05 Aug 2021 18:28:28 +0300 > > > > Patch is attached. This resolves the problem reported at > > https://github.com/emacs-evil/evil/issues/1504 > > Could you please describe the problem you are trying to solve, > preferably without involving Evil? Sure. The auto-revert-mode by default works with ‘revert-buffer-insert-file-contents--default-function’ function. This function is known to break markers in buffers, which is why recently Emacs has added a replacement function revert-buffer-insert-file-contents-delicately (the one I modify in the patch). However, actually trying to use this new function revealed a regression in behavior of another function: the `find-file`. Basically, if you have a file `/tmp/foo` opened in Emacs (IOW Emacs has a buffer associated with this file), and then file `/tmp/foo` gets "auto-reverted", then if you execute (find-file "/tmp/foo"), the new function causes Emacs ask a user "File foo was modified, do you want to revert it? (yes/no)". It now gives that prompt always, until you make a change to the buffer. That's a regression compared to the default behavior with `revert-buffer-insert-file-contents--default-function`. And the reason turned out to be that the function `revert-buffer-insert-file-contents--default-function` after having succesfully reverted a file, sets the buffer mtime to the mtime of the file. However the function revert-buffer-insert-file-contents-delicately didn't set mtime before that patch. I assume it is an omission from implementation, because technically that's incorrect: if the revert-buffer-insert-file-contents-delicately has successfully reverted a buffer, then we know that it has same content as the associated file, and hence it should have the same mtime.