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: Tue, 29 May 2018 21:06:01 +0200 Message-ID: <87a7sib7ty.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> 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 1527620718 3222 195.159.176.226 (29 May 2018 19:05:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 May 2018 19:05:18 +0000 (UTC) Cc: mail@bradyt.com, 31636@debbugs.gnu.org, Paul Eggert , npostavs@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 29 21:05:14 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 1fNjvl-0000iT-J5 for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 May 2018 21:05:13 +0200 Original-Received: from localhost ([::1]:34550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fNjxs-00011u-Lo for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 May 2018 15:07:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fNjxc-0000wz-Co for bug-gnu-emacs@gnu.org; Tue, 29 May 2018 15:07:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fNjxX-0006sq-EN for bug-gnu-emacs@gnu.org; Tue, 29 May 2018 15:07:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46436) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fNjxX-0006si-B3 for bug-gnu-emacs@gnu.org; Tue, 29 May 2018 15:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fNjxW-0006ie-DK for bug-gnu-emacs@gnu.org; Tue, 29 May 2018 15:07: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: Tue, 29 May 2018 19:07: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.152762077125766 (code B ref 31636); Tue, 29 May 2018 19:07:02 +0000 Original-Received: (at 31636) by debbugs.gnu.org; 29 May 2018 19:06:11 +0000 Original-Received: from localhost ([127.0.0.1]:54333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fNjwg-0006hW-S4 for submit@debbugs.gnu.org; Tue, 29 May 2018 15:06:11 -0400 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:55369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fNjwf-0006hK-Fh for 31636@debbugs.gnu.org; Tue, 29 May 2018 15:06:09 -0400 Original-Received: by mail-wm0-f46.google.com with SMTP id a8-v6so43326070wmg.5 for <31636@debbugs.gnu.org>; Tue, 29 May 2018 12:06:09 -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=4UnGrElk/zUJp8vdJaUKKkkU+cI9TqQlrJs1qW6Ngy4=; b=LF1L3ghBnz2wriVb7QhYulQuZwBejv8uFLLpYAGD82jHVuvtZYw4BFaFyVP/G56+zk k+A6kNM8nDzFW4GZu+r/gXrh59pxZl+LEmbfMC75GWBxZtNOWN5ULt1k5hwQGnoTSFrV j46KsWPvsRYaJg5X2NLzkPkkMJchGXAOVWV3E9bS8pcuk0qTocdH787ZOSg9xPNFfQdi VMVOdIYA+fjTTWKiTseI1cbp5mQ2VdPGvNu8EmANl8ccwmpvcyOZvq7qsmPWLlyeAqFe CmzIWdmLUCxQ5SnDV1aLxmT0HSkHtKrrCXXDoHlX9K1dcqfk9cisloVEsmIXbaS6DWSM iZaw== 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=4UnGrElk/zUJp8vdJaUKKkkU+cI9TqQlrJs1qW6Ngy4=; b=pKfCqyKlBtq/TPNWkjD0D3LmTZA4Q9p9FKw8qnCA2tTQS3+REU8lfjajZ5XFS1wXWL Je/5MyvQzv/OOE3U2HyCW30X0zAvUyeTCfM9V+YKxWsSuoUJ3Ta0Rq9I+CiIJU+UgWbW 1nwnhyQ8EO+Cnb3ZpjhYhfYw/CiGjKTJ3Za6bwnW/3TmlaZGWT6x1hOnkm+bu2/axicx uNBojjwDti6nn36jpzs7K4hD8zhPOArbIGEgOnciVliEodro3Swa3aU+0kLDXSbVi9JJ AUibQnaXkSup6ccoQW5reRvEEgAJhHUYqsbNf7P0RCfTWudRJ/d0eD4f+rYCKyhfF0GT fGlg== X-Gm-Message-State: ALKqPwezgFNc5n5v4/nebqCDV5sjSOL29KjqMqN4UzFKbu6zoQcXHwCr Guz1GPOe4gyrxxBrgBM445s= X-Google-Smtp-Source: ADUXVKK+9ulVh1IZuBUGqOGxzdfsEGIO6tCoDS3DZMKWn6D0gVQY4XxRGlQ1SJSGcKdFfvt6s4gayA== X-Received: by 2002:a1c:7309:: with SMTP id d9-v6mr97078wmb.60.1527620763748; Tue, 29 May 2018 12:06:03 -0700 (PDT) Original-Received: from rpluim (vav06-1-78-207-202-134.fbx.proxad.net. [78.207.202.134]) by smtp.gmail.com with ESMTPSA id s15-v6sm40414569wrg.70.2018.05.29.12.06.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 May 2018 12:06:02 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83r2luv28h.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 May 2018 19:46:38 +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:146714 Archived-At: Eli Zaretskii writes: > > 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). I understood the OP's concern to be that there was no obvious link from '.#' files and the fact that those files are used for locking. I don=CA=BCt see a need to put all the details about that locking in the doc string. > 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. See my previous paragraph: the goal is to inform the user that file locking is occurring, so the user manual is a good place to make that clear (without necessarily going into the gory details). > 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??). Not by me: I trust your taste. >> 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 >>=20=20 >> @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 See, I=CA=BCve learnt something from you again, and the end result will be better for it :-) > >> 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. How is it a half-truth? Is the lockfile name not constructed by prepending '.#' to the filename? >> 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. >>=20=20 >> -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. Makes sense. > 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? 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? Robert