From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Jay Berkenbilt" Newsgroups: gmane.emacs.bugs Subject: bug#53207: 28.0.91; create-lockfiles nil breaks file change detection Date: Thu, 13 Jan 2022 10:47:21 -0500 Message-ID: References: <509ddd0f-589c-45b0-9b60-5820f4c1d716@www.fastmail.com> <83sftr3nyx.fsf@gnu.org> <83h7a73fab.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11811"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.5.0-alpha0-4569-g891f756243-fm-20220111.001-g891f7562 Cc: Glenn Morris , Lars Ingebrigtsen , Michael Albinus , 53207@debbugs.gnu.org To: "Eli Zaretskii" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 13 16:49:16 2022 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 1n82Li-0002st-BX for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jan 2022 16:49:15 +0100 Original-Received: from localhost ([::1]:37334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n82Lg-0002Si-Uo for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jan 2022 10:49:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n82LW-0002Ry-LY for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 10:49:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41429) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n82LW-0003At-AJ for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 10:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n82LW-0007rh-9N for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 10:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Jay Berkenbilt" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Jan 2022 15:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53207 X-GNU-PR-Package: emacs Original-Received: via spool by 53207-submit@debbugs.gnu.org id=B53207.164208889830161 (code B ref 53207); Thu, 13 Jan 2022 15:49:02 +0000 Original-Received: (at 53207) by debbugs.gnu.org; 13 Jan 2022 15:48:18 +0000 Original-Received: from localhost ([127.0.0.1]:34332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n82Kn-0007qO-IH for submit@debbugs.gnu.org; Thu, 13 Jan 2022 10:48:17 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:41753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n82Kj-0007q4-K3 for 53207@debbugs.gnu.org; Thu, 13 Jan 2022 10:48:16 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A714032020F6; Thu, 13 Jan 2022 10:48:06 -0500 (EST) Original-Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Thu, 13 Jan 2022 10:48:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ql.org; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=lBeDn8+jhUSYT4x/0yg1syGzyTR8J7f DewwLZsu7z64=; b=b+58qgLWsDPskgauD+hU7UiC+AaSc15woqswV5dEFBkYxVb JByA76zeoSJ+pMxtK3KQGxADioMSVfrhW5dZHMZG0Yq2U4P7IKDidWUxlG54c+Sd nhjl0yZdvz93Kr1TrdyP5I0ug+fKy1qJnsj59eP1WtTXC5i+s/r6SCYSp6KHkYT5 0asWs8cHR08ErlyJz/1ui3NktcyieCxUlI02QHU6LWBrZN4GRRDVCI4SVkxAFcF9 rkOWMiCFQVQ5+M2ViRluWj4C9L+YX5sHfMH5BI8qMiwPgAjgEzVTImy7xh4y6DkG p2C4aSpxKEX3+wvAZOA3Fx/E7aq8mZHnsu2FxWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=lBeDn8 +jhUSYT4x/0yg1syGzyTR8J7fDewwLZsu7z64=; b=cjMZgs0XXLPm5GmZsB5+WK /KJMFPfLmJpAaYHHGfwalXBd4bmAs+WSZ6XIvAY7hoapNR0cCLJeqokD69IjrD1G cI555pk9771ORtazibov9G55fz9zRTtWR+yDMsXt/UtgKPUEUceMQwzz1B0o0xPi jKTDEx323k97b5puVZMhN1B8+YeWx/wmR3C0WaIXT9dd4hDmT/66zHyDJVC7Fsoy sYbZABQoyoq5PNhx0b7w0MSY86V29FBev5PMHzRR7DisVwyWpGyKw1Aq7GkugoWN geIDsdth5aoKy79tMEtiCkDSDSLJNYWQB/emEKW5CAsAW5m1RdvNjfzcVdUwypsA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdefgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedflfgrhicu uegvrhhkvghnsghilhhtfdcuoegvjhgssehqlhdrohhrgheqnecuggftrfgrthhtvghrnh ephedtvefhfedvfffgieefudehfefhudfhgeffgffftdevleffhedvvdehjeffueeknecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghjsgesqh hlrdhorhhg X-ME-Proxy: Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25291F60075; Thu, 13 Jan 2022 10:48:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <83h7a73fab.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:224120 Archived-At: On Thu, Jan 13, 2022, at 9:02 AM, Eli Zaretskii wrote: > > Date: Thu, 13 Jan 2022 08:11:34 -0500 > > From: "Jay Berkenbilt" > > Cc: 53207@debbugs.gnu.org > > > > For my edification, can you explain how the 27.2 behavior of noticing > > when a file's contents had changed immediately is not adequate without > > lockfiles? > > First, Emacs 27 wasn't looking at the file's contents, it was looking > at the file's modification time. My original recipe for reproducing the issue demonstrated that, after "touch file", you can continue editing freely and save, but after changing the contents, you can't. I don't remember when this first changed, maybe emacs 27 or 26. For ages before that, it was modification time. I remember noticing when updating the modtime without changing the content stopped triggering that. I was delighted. It is definitely the case that just updating the modification time on emacs 27.2 does not trigger this. You can try it. In emacs -Q, edit a file and save. From the shell, touch the file. No continue editing the file and save again. No warning. At least this is the case on my Ubuntu Linux 20.04 system with emacs compiled from source. > > It seems to me that there are two separate issues here. A lock file > > would enable you to immediately notice if a user on a *different > > system* is in the process of editing a file and has unsaved changes. > > No, it also works when the same user on the same system edited the > file from another Emacs session. That is a valid use case: some > people start more than a single Emacs session on the same system. Granted. Of course it doesn't protect against another very common use case, which is people opening the same file in emacs and simultaneously in something like VS Code or another IDE. I know developers that work this way day in and day out -- they use emacs for most of their editing but hop over to an IDE to take advantage of project-wide integrations, better test integration, a more advanced debugger, or better out-of-the-box functionality with their programming language or environment of choice. So lock files remain a solution that only works in an emacs-only environment, while noticing that the file's modification time has changed is universal, and noticing that a file's content has changed is a great advancement over just noticing modtime since it allows for workflows like git rebase. > > On the other hand, the other behavior I'm talking about allows you to > > notice immediately when you begin editing if the file on disk has > > become out of sync with the buffer contents. > > That part is done when you save the buffer. It is unaffected by > create-lockfiles. It is also done when you start editing a buffer, as shown in my original message. Really. Try it.