all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: mail@bradyt.com, 31636@debbugs.gnu.org, eggert@cs.ucla.edu,
	npostavs@gmail.com
Subject: bug#31636: 27.0.50; lockfile syntax searchable from info manual
Date: Fri, 01 Jun 2018 12:47:54 +0200	[thread overview]
Message-ID: <87h8mmu6jp.fsf@gmail.com> (raw)
In-Reply-To: <20180529073311.EEA09102DA@mailuser.nyi.internal>

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: mail@bradyt.com,  31636@debbugs.gnu.org,  eggert@cs.ucla.edu,  npostavs@gmail.com
>> Date: Thu, 31 May 2018 12:29:54 +0200
>> 
>> Do we want a '.#' index entry in the lispref as well?
>
> Yes.
>

Done.

>> Do I need to explain that USER will be replaced by the current user,
>> etc?
>
> Yes, I think so.

I should have known better than to ask. Done. I even gritted my teeth
and wrote "Emacs's".

> This should use @var{user}, @var{host} etc. for the components of the
> target file name, and it should explain shortly what each component
> stands for.

I donʼt see any difference in the visual appearance from using @var,
but I made the change anyway, and expanded the explanation (I noticed
that texinfo.el has no bindings for inserting @ref, @xref, and @pxref,
should I add some?  C-cC-c[rp] are free, but x is already used for
@example, so 'C-cC-cX'? Or maybe 'C-cC-cC-x' for @xref?)

> Here I would say that the name of the lockfile is constructed by
> prepending a '.#' to the name of the file being locked.

Done.

2018-05-31  Robert Pluim  <rpluim@gmail.com>

	* 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.  Add index entry for '.#' to
	improve disoverability of information about locking.

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
 
 @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 lock
-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.
 
 @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..012a7a0a7c 100644
--- i/doc/lispref/files.texi
+++ w/doc/lispref/files.texi
@@ -712,6 +712,7 @@ File Locks
 @section File Locks
 @cindex file locks
 @cindex lock file
+@cindex .#, lock file names
 
   When two users edit the same file at the same time, they are likely
 to interfere with each other.  Emacs tries to prevent this situation
@@ -720,8 +721,17 @@ 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{@var{user}@@@var{host}.@var{pid}:@var{boot}}, where @var{user}
+is replaced with the current username (from @code{user-login-name}),
+@var{host} with the name of the host where Emacs is running (from
+@code{system-name}), @var{pid} with Emacs's process id, and @var{boot}
+with the time since the last reboot.  @code{:@var{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{@var{user}@@@var{host}.@var{pid}:@var{boot}}.)
 
   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..d33063c879 100644
--- i/src/filelock.c
+++ w/src/filelock.c
@@ -849,7 +849,10 @@ syms_of_filelock (void)
   Vtemporary_file_directory = Qnil;
 
   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 name of the (per-buffer) lockfile is constructed by prepending a
+'.#' to the name of the file being locked.  See also `lock-buffer' and
+Info node `(emacs)Interlocking'.  */);
   create_lockfiles = 1;
 
   defsubr (&Sunlock_buffer);





  reply	other threads:[~2018-06-01 10:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29  7:33 bug#31636: 27.0.50; lockfile syntax searchable from info manual Brady Trainor
2018-05-29  8:40 ` Robert Pluim
2018-05-29 11:24   ` Noam Postavsky
2018-05-29 13:17     ` Robert Pluim
2018-05-29 16:46       ` Eli Zaretskii
2018-05-29 19:06         ` Robert Pluim
2018-05-30  2:42           ` Eli Zaretskii
2018-05-31 10:29             ` Robert Pluim
2018-06-01  8:52               ` Eli Zaretskii
2018-06-01 10:47                 ` Robert Pluim [this message]
2018-06-01 13:00                   ` Eli Zaretskii
2018-06-01 13:24                     ` Robert Pluim
2018-06-01 13:25                     ` Robert Pluim
2018-06-01 13:42                       ` Robert Pluim
2018-06-04  9:41                         ` Robert Pluim
2018-06-04 10:39                           ` Andreas Schwab
2018-06-04 14:02                             ` Robert Pluim
2018-06-04 16:06                               ` Eli Zaretskii
2018-06-04 15:55                           ` Eli Zaretskii
2018-06-04 17:17                             ` Robert Pluim
2018-06-05 15:07                               ` Eli Zaretskii
2018-06-05 19:51                                 ` Robert Pluim
2018-06-05 20:08                                   ` Noam Postavsky
2018-06-06  7:43                                     ` Robert Pluim
2018-06-06 13:13                                       ` Noam Postavsky
2018-06-06 13:51                                         ` Robert Pluim
2018-06-06 14:41                                           ` Noam Postavsky
2018-06-06 14:51                                             ` Robert Pluim
2018-05-29 19:20         ` Paul Eggert
2018-05-30  2:42           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h8mmu6jp.fsf@gmail.com \
    --to=rpluim@gmail.com \
    --cc=31636@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=mail@bradyt.com \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.