From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#31636: 27.0.50; lockfile syntax searchable from info manual Date: Thu, 31 May 2018 12:29:54 +0200 Message-ID: <87wovkyv6l.fsf@gmail.com> References: <20180529073311.EEA09102DA@mailuser.nyi.internal> <876036hn2e.fsf@gmail.com> <87tvqqd7rp.fsf@gmail.com> <87r2lufvo9.fsf@gmail.com> <83r2luv28h.fsf@gnu.org> <87a7sib7ty.fsf@gmail.com> <83in75vp8l.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1527762555 8898 195.159.176.226 (31 May 2018 10:29:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 10:29:15 +0000 (UTC) Cc: mail@bradyt.com, 31636@debbugs.gnu.org, eggert@cs.ucla.edu, npostavs@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 31 12:29:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOKpS-0002CI-13 for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 May 2018 12:29:10 +0200 Original-Received: from localhost ([::1]:42996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOKrX-0006yx-7t for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 May 2018 06:31:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOKrJ-0006y5-Sa for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 06:31:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOKrG-0004Jq-Mx for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 06:31:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47751) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOKrG-0004JK-Hk for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 06:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fOKrG-0004Nu-42 for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 06:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 May 2018 10:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31636-submit@debbugs.gnu.org id=B31636.152776260716789 (code B ref 31636); Thu, 31 May 2018 10:31:02 +0000 Original-Received: (at 31636) by debbugs.gnu.org; 31 May 2018 10:30:07 +0000 Original-Received: from localhost ([127.0.0.1]:55648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOKqM-0004Mj-Gq for submit@debbugs.gnu.org; Thu, 31 May 2018 06:30:06 -0400 Original-Received: from mail-wm0-f54.google.com ([74.125.82.54]:56228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOKqK-0004Kx-3v for 31636@debbugs.gnu.org; Thu, 31 May 2018 06:30:04 -0400 Original-Received: by mail-wm0-f54.google.com with SMTP id a8-v6so53045005wmg.5 for <31636@debbugs.gnu.org>; Thu, 31 May 2018 03:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list :date:in-reply-to:message-id:mime-version:content-transfer-encoding; bh=upnTFDeMGlYDwrdbOEb3SZyzghiG+ZDT/TegrnpeAMI=; b=VPW7jVRnJxpyRAb6PIBoQuGBNelUQK6OnA73MdIrpEwXA2dgEBamJyjhZGpYOL70lx vsZ8IGiOkNxwIFYVMWIZuK5jgMwfgU6Hh9PiuFv3/ZHH56mWwRRMAcQaeGeFwapuk0EK AVtzICbpIxNP4aqT8PM0o+DGxveiDlXaXj+4lPrTA7eWOKDWKXfKelk5nHanU3nUAIlr MSmUbSL4M4AFwNJZQEVnZpM2h2Mlh7BGoe2uXs5T5IVObjNXHKhbUywZrtIn/IpJuN+E c2BEJPcnDYxAV9iwlINiDCG6FozraV6Ni62a0ytbIPA9NfuJoIup5WU7tWsgOOlkKmLi IERQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=upnTFDeMGlYDwrdbOEb3SZyzghiG+ZDT/TegrnpeAMI=; b=DAdkSP9+52kfDf1WBZ/fT9Y/RCsaLt0SxG2ByLcFKIn40e6YxEadJQ/fzw9X1ZwvFc m3j5HWSNRTb1tx69q/FNJrebl71j8EuH7EdETDGIQPld+Ptvh4obyjkJP2i627WZunsF vRMH+Kx/XZHTqpkNWj6AXo8aB80XTd+UOkrBu3jK5MFpEIfUzUZupCL2EAGpkEmOrpp9 GxCP4PuCqgcuQrALSPTUDEU74DUqKrYBRRKCzQJ8bcS2Tnk/SEIDnxDrXwbOLi45hamw Nj12p4M2eK7g3ZLh3F2fxE/ygDdjKHteTNE/z7f/5J9+p1d/o+2G3lc1B30+TqIIG1BV D5lQ== X-Gm-Message-State: APt69E1rxIw7F3e5BkGPaLu8rEEVs4+wgv0X6WtqKIX/oDyrN3wgD22Q VsrMYXpMAZfYkONGjW8221k= X-Google-Smtp-Source: ADUXVKLHq/nmsPSITy6pw5fsuoi3iaqiHdPkiN1THdDJRhxwvraAMqJ1IHa/tt9jC4Rw2Y9I8Qqejg== X-Received: by 2002:a1c:824b:: with SMTP id e72-v6mr3874150wmd.64.1527762598372; Thu, 31 May 2018 03:29:58 -0700 (PDT) Original-Received: from rpluim ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id a69-v6sm800196wma.7.2018.05.31.03.29.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 May 2018 03:29:57 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83in75vp8l.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 May 2018 05:42:02 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:146770 Archived-At: Eli Zaretskii writes: >> > As I said above, I think if we are describing this in more detail, why >> > not describe also the information recorded in the lockfile? If >> > someone looked up the lockfile name, someone else may wish to look up >> > the data it records and understand what that is, no? >>=20 >> Didn=CA=BCt you make the point just now that this kind of detail could >> change and we=CA=BCd forget to update the documentation? Or did you want >> this in the elisp manual? > > The latter. So what I currently have is below. create-lockfiles references the user manual (and 'lock-buffer') which in turn references the lisp reference manual. Do we want a '.#' index entry in the lispref as well? Do I need to explain that USER will be replaced by the current user, etc? Let the wordsmithing begin! 2018-05-31 Robert Pluim * src/filelock.c (create-lockfiles): Add cross reference to file locking in user manual and to 'lock-buffer'. Add string '.#' to help users find the doc string. * doc/emacs/files.texi (Interlocking): Point user at detailed file locking description in lisp reference manual. Add index entry for '.#' to improve disoverability of information about locking. * doc/lispref/files.texi (File Locks): Describe in detail what the form of the lock file is. diff --git i/doc/emacs/files.texi w/doc/emacs/files.texi index 1ced7ca07c..406e7d980c 100644 --- i/doc/emacs/files.texi +++ w/doc/emacs/files.texi @@ -766,13 +766,16 @@ Interlocking =20 @findex ask-user-about-lock @cindex locking files +@cindex .#, lock file names +@cindex file locking When you make the first modification in an Emacs buffer that is visiting a file, Emacs records that the file is @dfn{locked} by you. (It does this by creating a specially-named symbolic link@footnote{If your file system does not support symbolic links, a regular file is -used.} with special contents in the same directory.) Emacs removes the lo= ck -when you save the changes. The idea is that the file is locked -whenever an Emacs buffer visiting it has unsaved changes. +used.} with special contents in the same directory. @xref{File +Locks,,, elisp} for more details.) Emacs removes the lock when you +save the changes. The idea is that the file is locked whenever an +Emacs buffer visiting it has unsaved changes. =20 @vindex create-lockfiles You can prevent the creation of lock files by setting the variable diff --git i/doc/lispref/files.texi w/doc/lispref/files.texi index f62b670f47..89a98bd588 100644 --- i/doc/lispref/files.texi +++ w/doc/lispref/files.texi @@ -720,8 +720,13 @@ File Locks Emacs can then detect the first attempt to modify a buffer visiting a file that is locked by another Emacs job, and ask the user what to do. The file lock is really a file, a symbolic link with a special name, -stored in the same directory as the file you are editing. (On file -systems that do not support symbolic links, a regular file is used.) +stored in the same directory as the file you are editing. The name is +constructed by prepending @file{.#} to the filename of the buffer. +The target of the symbolic link will be of the form +@code{USER@@HOST.PID:BOOT}. @code{:BOOT} is omitted if the boot time +is unavailable. (On file systems that do not support symbolic links, +a regular file is used instead, with contents of the form +@code{USER@@HOST.PID:BOOT}.) =20 When you access files using NFS, there may be a small probability that you and another user will both lock the same file simultaneously. diff --git i/src/filelock.c w/src/filelock.c index f2dc723407..4f7ec414f5 100644 --- i/src/filelock.c +++ w/src/filelock.c @@ -849,7 +849,9 @@ syms_of_filelock (void) Vtemporary_file_directory =3D Qnil; =20 DEFVAR_BOOL ("create-lockfiles", create_lockfiles, - doc: /* Non-nil means use lockfiles to avoid editing collisions. = */); + doc: /* Non-nil means use lockfiles to avoid editing collisions. +The names of the lockfiles will start with `.#'. See also +`lock-buffer' and Info node `(emacs)Interlocking'. */); create_lockfiles =3D 1; =20 defsubr (&Sunlock_buffer);