From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: CLASH_DETECTION option in configure Date: Tue, 12 Feb 2013 13:55:36 -0700 Message-ID: <20130212205536.GA12941@hysteria.proulx.com> References: <20130130145503.54e2572bafd6283f61956823@lavabit.com> <31ip6edzxd.fsf@fencepost.gnu.org> <20130203151143.b0e727fa15c48fccee3a4dbc@lavabit.com> <20130203233659.GA30144@hysteria.proulx.com> <20130204163259.69cffecc682fa6d6390d66cb@lavabit.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1360702555 20193 80.91.229.3 (12 Feb 2013 20:55:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Feb 2013 20:55:55 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Feb 12 21:56:17 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U5Mth-0003zu-N5 for geh-help-gnu-emacs@m.gmane.org; Tue, 12 Feb 2013 21:56:13 +0100 Original-Received: from localhost ([::1]:44932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5MtO-0005YJ-F0 for geh-help-gnu-emacs@m.gmane.org; Tue, 12 Feb 2013 15:55:54 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5MtF-0005RK-9l for help-gnu-emacs@gnu.org; Tue, 12 Feb 2013 15:55:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U5Mt9-0001KT-Sb for help-gnu-emacs@gnu.org; Tue, 12 Feb 2013 15:55:45 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:40733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5Mt9-0001KC-JL for help-gnu-emacs@gnu.org; Tue, 12 Feb 2013 15:55:39 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 8028E211DF for ; Tue, 12 Feb 2013 13:55:37 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 3D0492DCDE; Tue, 12 Feb 2013 13:55:36 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <20130204163259.69cffecc682fa6d6390d66cb@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:89090 Archived-At: rh wrote: > Bob Proulx wrote: > > rh wrote: > > > It seems like an antiquated feature and it doesn't make sense to > > > have it enabled by default. Since version control systems are every > > > where now I can't see why anyone would want or use this feature. > > > What's the use case? > > > > If you as a single user try to edit a file from two different > > terminals then it will be detected and a collision avoided. I often > > run into cases where emacs notifies me that I am already editing a > > file in another terminal. The use case is far from antiquated and has > > nothing to do with version control. Because unintended data loss can > > result if it were disabled the feature is enabld by default. > > We may or may not be talking about the same feature. It's possible > that we are not. Possibly! :-) > With this feature disabled emacs stills tells asks me if I really > want to edit this buffer. So did I think I disabled but didn't? But > I no longer find those .#filename->hostname files laying around > either. There are two or three similar but related features. One of them looks at the timestamps of the files. One of them looks at the lock information stored in a symlink. A third notifies if a buffer save is newer than the current file. 1. /tmp/foo locked by rwp@example.... (pid 14294): (s, q, p, ?)? This uses uses a symlink in the typical way to store information. lrwxrwxrwx 1 40 Feb 12 13:16 .#foo -> rwp@example.14294:1358485837 2. foo changed on disk; really edit the buffer? (y, n, r or C-h) foo has changed since visited or saved. Save anyway? (yes or no) 3. foo has auto save data; consider M-x recover-this-file This uses a buffer save file #foo# to hold the buffer save. > > I will turn the same question around on you. Why would you ever want > > to disable this feature? Why is it causing you difficulty? If as you > > say you would never hit this issue then you should also by that same > > reasoning never know it is there either. > > Those .#filename->hostname files were the clue. My takeaway from this is that the meta-data files created by emacs in the local directory annoy you and you would like emacs to not make those files there. It isn't about the behavior but about the lint that is placed in the directory to support the feature. Since there are customizations available to turn off backups (setq make-backup-files nil) and to move the buffer save file out of the current directory (see backup-directory-alist variable) it would make sense if there were also a control to change the directory for lock symlinks too. And actually backup-directory-alist seems like it should affect both. But when I tried backup-directory-alist just now I couldn't get it to function for me. Don't know why. Bob