From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Proposed patch: allow user to disable lockfile creation Date: Sun, 31 Jul 2011 12:13:06 +1000 Message-ID: References: <87ei1bqi8p.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1312078407 29618 80.91.229.12 (31 Jul 2011 02:13:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 02:13:27 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 04:13:15 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QnLWj-0006Vi-RQ for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 04:13:15 +0200 Original-Received: from localhost ([::1]:43324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnLWh-0003hB-UD for ged-emacs-devel@m.gmane.org; Sat, 30 Jul 2011 22:13:11 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnLWf-0003h6-A9 for emacs-devel@gnu.org; Sat, 30 Jul 2011 22:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnLWe-0004VX-9W for emacs-devel@gnu.org; Sat, 30 Jul 2011 22:13:09 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:37069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnLWe-0004VR-4n for emacs-devel@gnu.org; Sat, 30 Jul 2011 22:13:08 -0400 Original-Received: by iyb14 with SMTP id 14so6892281iyb.0 for ; Sat, 30 Jul 2011 19:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=k3MLmSnCOLGld6FUQBeD5S7elplBuj+qIUg8FXiww5A=; b=O0rjVhwaXnI/LUUma1QUnUliTS0Nehrt30hza9V1h0xMC8hV9LusvF+LSnRrWHREln 0/bCaTsqEwwuSIvOFCgqN8/JnI1za+VwIYuVwKSciuYU0eHgmKwdGbT7DfKSpqOwouyK w1O37Ln+ME7JkJgwLo53WNvBynixAoQQdxW0M= Original-Received: by 10.231.197.16 with SMTP id ei16mr1933396ibb.111.1312078386848; Sat, 30 Jul 2011 19:13:06 -0700 (PDT) Original-Received: by 10.231.35.74 with HTTP; Sat, 30 Jul 2011 19:13:06 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142533 Archived-At: On Fri, Jul 29, 2011 at 10:51 AM, Dave Abrahams wrote: > > on Thu Jul 28 2011, Tim Cross wrote: > >> It seems that the issue isn't really about conflict detection per se, >> but rather how emacs implements it via symlinks. > > It's actually more than that. =A0The scheme is simultaneously > over-cautious and yet full of holes. =A0It's predicated on the idea that > everybody who might touch the file simultaneously is using Emacs, but > that's obviously a fallacy. =A0Any program that doesn't respect Emacs' > convention and look for the lock file (e.g. every command-line tool in > existence) will happily write the file even when I have a lock on it. > Furthermore, Emacs is perfectly capable of telling me when that has > happened before I save... at least it seems to work pretty darned > reliably. =A0So I think this feature made sense once upon a time but is > now just a vestigial flipper. > > Am I missing something? =A0I could be. > Sorry, a bit confused now. Are you saying there is no need for emacs to do any form of conflict resolution at all? From what others have posted, my impression was that the current implementation was a problem and therefore, there was a request to be able to turn it off. My feeling was that conflict resolution is not a bad thing in itself and if properly implemented, would achieve its desired goal without getting in the way and therefore, without the need to be able to turn it on or off. Hence my suggestion to look at OS provided facilities, which may have matured to the point they could be used instead of what is seen by some, as emacs' old and outdated approach. However, I will also say I probably don't understand the problem. I've been using emacs daily since the mid 90's and have yet to encounter a problem with this aspect of the software, so I don't quite understand why it is even an issue, apart from possible aesthetic reasons, which are fine, but difficult to get consensus on. Tim