unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Robert Pluim <rpluim@gmail.com>, Paul Eggert <eggert@cs.ucla.edu>
Cc: mail@bradyt.com, 31636@debbugs.gnu.org, npostavs@gmail.com
Subject: bug#31636: 27.0.50; lockfile syntax searchable from info manual
Date: Tue, 29 May 2018 19:46:38 +0300	[thread overview]
Message-ID: <83r2luv28h.fsf@gnu.org> (raw)
In-Reply-To: <87r2lufvo9.fsf@gmail.com> (message from Robert Pluim on Tue, 29 May 2018 15:17:26 +0200)

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 29 May 2018 15:17:26 +0200
> Cc: Brady Trainor <mail@bradyt.com>, 31636@debbugs.gnu.org
> 
> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 29 May 2018 10:19:16 +0200
> Subject: [PATCH] Add more discoverable documentation for '.#'
> To: emacs-devel@gnu.org
> 
> * doc/emacs/files.texi (Interlocking): Add index entry for '.#' and
> mention its use in lockfile names.
> 
> * src/filelock.c (Flock_buffer): Mention '.#' string, add reference to
> Interlocking info node.
> ---
>  doc/emacs/files.texi | 4 +++-
>  src/filelock.c       | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)

Hmm...  I'm okay with describing this in the doc string (and then
perhaps also describe the info recorded in the symlink? it doesn't
sound like it is less important than the exact file name).  But I'm
not sure we want to add this to the manual.  First, the current text
clearly tries not to divulge the exact way of computing the name of
the lockfile.  Second, if and when this changes (and we've seen
changes there just a year or two ago), someone will need to remember
to go back and update the manual, which they will surely forget, which
then will leave outdated information in the manual.  Finally, this is
not really a user-level stuff, so the user manual is not a good place
for it to begin with.

I'd be interested to hear Paul's take on this, as someone who worked
on the related code not too long ago.  Paul?

Below I comment on the manual part of the patch, in case I will be
outvoted eventually (whaat? how??).

> diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
> index 1ced7ca07c..72d538161a 100644
> --- a/doc/emacs/files.texi
> +++ b/doc/emacs/files.texi
> @@ -766,9 +766,11 @@ Interlocking
>  
>  @findex ask-user-about-lock
>  @cindex locking files
> +@cindex .#

This index entry is not useful.  Imagine a reader looking at the entry
in the index -- will they understand what it's about?  Probably not.

Instead, I'd use this:

  @cindex .#, lock file names

>    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
> +(It does this by creating a specially-named symbolic link, whose name
> +contains the string @code{.#} @footnote{If

"Contains the string" is again a half-truth.  It sounds like this bug
report is against telling half-truths.

> diff --git a/src/filelock.c b/src/filelock.c
> index f2dc723407..042fe9e00b 100644
> --- a/src/filelock.c
> +++ b/src/filelock.c
> @@ -773,7 +773,9 @@ DEFUN ("lock-buffer", Flock_buffer, Slock_buffer,
>  FILE defaults to current buffer's visited file,
>  or else nothing is done if current buffer isn't visiting a file.
>  
> -If the option `create-lockfiles' is nil, this does nothing.  */)
> +If the option `create-lockfiles' is nil, this does nothing.
> +The name of the lockfile used contains '.#', see
> +Info node `(emacs)Interlocking' for more information.  */)

The place where you describe the form of the file name is
sub-optimal.  I'd instead do this in the doc string of
create-lockfiles, it seems much more natural there.  And I'd also add
there a link to the doc string of lock-buffer.

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?

Thanks.





  reply	other threads:[~2018-05-29 16:46 UTC|newest]

Thread overview: 15+ 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 [this message]
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
2018-06-01 13:00                   ` Eli Zaretskii
2018-06-01 13:24                     ` Robert Pluim
2018-06-01 13:25                     ` 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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83r2luv28h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=31636@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=mail@bradyt.com \
    --cc=npostavs@gmail.com \
    --cc=rpluim@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).